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1  Introduction 

1.1  Goals  and  Objectives 

The  Penelope  Ada  proof  editor  allows  a  user  to  incrementally  develop  provably  correct  Ada 
programs.  The  current  version  of  the  Penelope  system  is  formally  based  on  a  predicate 
transformer  semantics  for  sequential  Ada.  The  purpose  of  this  work  is  to  provide  the  math¬ 
ematical  foundations  for  extending  Penelope  to  Ada  tasking  programs.  Several  issues  need 
to  be  addressed  to  this  end. 

1.  A  suitable  logical  formalism  needs  to  be  defined  within  which  it  is  possible  to  reason 
about  concurrent  programs.  In  the  case  of  sequential  programs  first-order  logic  was 
sufficient  for  this  purpose. 

2.  A  specification  and  an  annotation  language  must  be  defined  for  stating  properties  of 
concurrent  programs.  In  the  case  of  sequential  programs  input /output  conditions  and 
loop  invariants  are  used  as  specifications. 

3.  A  method  for  defining  the  semantics  of  Ada  needs  to  be  devised.  Given  a  program 
and  a  specification,  it  must  be  possible  to  derive  conditions  under  which  the  program 
will  satisfy  its  specifications.  This  step  corresponds  to  the  generation  of  verification 
conditions  in  the  sequential  case. 

4.  An  effective  proof  procedure  must  be  found  for  showing  that  the  that  correctness 
conditions  generated  for  a  program  are  true.  If  first-order  logic  is  used,  then  a  first- 
order  theorem  prover  will  suffice,  in  the  concurrent  case  a  theorem  prover  for  a  richer 
language  will  be  needed. 

5.  Finally,  a  new  methodology  for  the  systematic  development  of  correct  tasking  programs 
needs  to  be  developed.  This  includes  ways  to  formally  express  problem  specification, 
to  find  proper  program  annotations  and  so  on. 

This  document  addresses  primarily  the  first  three  questions.  While  an  appropriate  notion 
of  proof  is  formally  defined  within  our  mathematical  framework,  issues  of  the  engineering  of 
a  practical  theorem  prover  are  not  discussed.  The  use  of  the  new  formalism  for  proving  the 
correctness  of  tasking  programs  is  demonstrated  with  several  programming  examples.  But 
the  development  of  a  verification  methodology  requires  more  extensive  experience. 

There  are  a  number  of  desiderata  for  the  formalism. 

1.  The  specification  method  must  be  compositional  and  must  support  abstractions.  This 
is  to  say,  that  the  meaning  of  a  concurrent  program  can  be  determined  from  the 
meaning  of  its  parts  and  that  these  parts  can  be  separately  specified  and  proved  correct. 

Compositionality  is  important  so  the  one  can  break  down  complex  proofs  into  smaller, 
manageable  ones.  Compositionality  is  difficult  to  achieve  for  concurrent  programs  since 
their  semantics  depends  on  the  possible  interaction  of  all  processes. 
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2.  Program  annotations  must  express  the  intended  behavior  in  a  natural  way.  The  spec¬ 
ifications  of  a  program’s  parts  should  correspond  to  notions  of  the  designer  and  pro¬ 
grammer. 

3.  There  must  be  reasonably  efficient  proof  procedures  for  the  formal  correctness  state¬ 
ments.  Given  that  fully  automated  proofs  are  not  likely  (and  impossible  in  general), 
it  is  important  that  the  formulas  arising  during  proofs  are  meaningful  to  the  human 
verifier  and  that  they  can  be  related  to  the  program  text. 

The  approach  taken  here  is  based  on  the  concepts  of  process  algebra,  an  abstract,  algebraic 
description  of  the  observable  behavior  of  processes  [87,  18,  57].  Process  algebra  is  composi¬ 
tional,  leads  to  fairly  natural  specifications,  and  has  well  understood  proof  procedures.  The 
technique  is  fairly  mature  and  other  formal  specification  languages  such  as  LOTOS  ([22]) 
and  the  RAISE  specification  language  ([44])  are  also  based  on  process  algebra. 

The  contribution  of  this  work  is  twofold.  First,  it  defines  process  logic  which  combines 
first-order  logic  with  process  algebra^.  The  former  allows  the  specification  of  the  state  of  a 
computation  while  the  latter  describes  the  possible  sequences  of  observable  events.  Secondly, 
a  technique,  based  on  predicate  transformers,  is  defined  for  using  process  logic  to  specify  and 
verify  concurrent  programs. 

Using  process  logic  it  is  possible  to  express  the  communication  behavior  of  a  code  fragment 
in  terms  of  pre-  and  post-processes.  I.e.  process  terms  are  used  in  place  of  pre-  and  post¬ 
conditions.  The  method  is  compositional  in  the  sense  that  the  pre-  and  post-process  of 
a  composite  language  construct  are  defined  in  terms  of  the  pre-  and  post-processes  of  its 
constituents. 

Even  though  process  logic  can  express  divergence,  termination,  and  deadlock,  the  proposed 
specification  technique  deals  only  with  partial  correctness.  The  reason  is  that  as  in  the 
sequential  case,  loop  invariants  and  pre-  and  post-processes  are  used  to  reason  about  iteration 
and  recursion. 

The  technique  assumes  a  message  passing  semantics  of  concurrency.  I.e.,  the  computational 
model  assumes  a  set  of  processes  with  local  state  that  communicate  through  messages.  In 
particular,  the  method  does  not  deal  directly  with  shared  memory  concurrency.  Of  course, 
shared  memory  accesses  can  always  be  viewed  as  communications  with  a  central  shared 
memory  process.  The  method  is  applied  to  Ada  by  specifying  predicate  transformers  for 
Ada  tasking  construct.  But  the  definition  of  process  logic  is  independent  of  Ada  and  can  be 
applied  to  other  languages. 

The  method  described  here  satisfies  the  above  criteria  to  large  degree.  Predicate  transformers 
are  a  natural  mechanism  for  several  reasons.  Program  specifications  can  be  expressed  through 
pre-  and  post-processes  on  code  fragments.  Program  verification  proceeds  in  a  manner 

'The  term  process  logic  is  sometimes  used  (e.g.  in  [94])  to  refer  to  Hennessy-Milner  logic  ([55]).  The  use 
of  the  term  in  the  present  context  has  historic  reasons  since  early  version  of  this  work  were  based  on  a  modal 
logic  approach. 
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familiar  from  sequential  verification:  For  a  given  program  with  annotations  the  verifier  will 
generate  verification  conditions  which  are  shown  to  be  valid  by  a  theorem  prover. 


1.2  Specifying  Concurrent  Systems 

Concurrency  is  used  on  a  number  of  levels  in  software  systems.  Different  usages  may  require 
different  formal  models.  It  is  therefore  important  to  define  the  kinds  of  applications  and 
correctness  properties  that  we  are  interested  in. 

One  class  of  problems  that  are  of  no  interest  here  involves  low-level  concurrency  such  as  the 
implementation  of  mutual  exclusion  in  terms  of  shared  variables  with  atomic  assignment, 
or  the  correctness  proof  of  an  on-the-fiy  garbage  collector  ([39]).  Rather,  the  problems  of 
interest  involve  concurrent  processes  that  communicate  with  each  other  through  message 
passing.  It  is  assumed  that  on  this  level  suitable  process  abstractions  are  available.  Issues  of 
the  correct  implementation  of  processes  abstraction,  of  the  fairness  of  the  system  scheduler, 
and  so  on  are  of  no  concern  here.  The  view  taken  here  is  very  broad  and  includes  all 
components  of  a  system.  These  need  not  be  software  artifacts  but  may  involve  hardware 
devices.  The  correctness  of  a  software  component  of  such  a  larger  system  needs  to  be  proved 
in  the  context  of  its  environment.  The  Ada  tasking  model  supports  this  more  abstract  view 
where  devices  interact  with  Ada  tasks  through  interrupts  mapped  to  entry  calls. 

The  typical  system  of  interest  might  be  a  reactive  system  that  responds  to  a  set  of  possible 
stimuli  by  certain  actions.  For  example,  the  control  system  of  a  reactor  receives  inputs 
from  a  number  of  pressure  and  temperature  sensors  and  has  to  properly  respond  by  issuing 
appropriate  signals  to  control  valves,  sound  alarms  and  so  on.  Within  our  formal  model  it  is 
possible  to  describe  the  behavior  of  such  a  control  system  as  well  as  the  reactor  itself.  It  is 
then  possible  to  formally  evaluate  their  mutual  interaction.  Eventually,  the  control  system 
or  significant  parts  of  it  will  be  implemented  in  software  in  a  suitable  high-level  language 
(e.g.  Ada). 

Most  of  the  systems  specified  are  likely  to  be  non-terminating.  In  fact,  termination  of  a 
control  system  might  be  a  fatal  error.  Rather,  the  kind  of  termination  properties  one  is 
interested  in  are  called  liveness  properties  (e.g.  [72,  7]).  Liveness  means  that  the  program 
is  guaranteed  to  make  progress  and  will  eventually  respond.  By  contrast,  safety  properties 
guarantee  that  the  program,  if  it  responds,  will  respond  properly.  (See  [1]  for  a  topological 
definition  of  safety  and  liveness.) 

In  general,  liveness  may  be  violated  by  non-termination,  either  due  to  non-termination  of 
a  sequential  program  fragment  or  infinite  internal  communication.  The  former  situation 
requires  termination  proofs  of  all  sequential  fragments.  The  latter  case  also  amounts  to 
termination:  on  some  level  of  abstraction  it  is  not  observable  whether  internal  computation 
involves  communication  or  not.  The  present  work  is  only  concerned  with  safety  properties, 
i.e.,  the  causal  relation  between  events  and  with  the  correctness  of  associated  data.  This  can 
be  remedied,  however,  by  using  standard  well-foundedness  arguments  to  prove  termination 
of  sequential  program  parts. 
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In  practice  one  is  not  only  concerned  with  termination  but  also  with  the  actual  time  it 
takes  to  respond  to  certain  events.  Timing  constraints  are  not  treated  here.  There  are 
several  reasons  for  omitting  timing  consideration.  One  important  problem  is  that  the  timing 
behavior  of  a  program  is  not  a  property  of  the  source  code  but  depends  on  a  large  number  of 
other  factors  such  as  compilation  techniques,  processor  performance,  distribution  and  so  on. 
At  least  in  principle,  process  algebra  can  be  extended  to  deal  with  real-time  (see  e.g.  [16]). 
Henzinger  ([56])  discusses  the  notion  of  liveness  in  the  context  of  timing  constraints. 

Another  property  of  concurrent  programs  is  fairness.  An  execution  is  not  fair  if  some  service 
request  is  ignored  for  ever.  This  situation  may  arise  if  the  program  performs  useful  work  on 
other  tasks.  Process  logic  cannot  express  fairness  in  this  abstract  form.  This  is  no  big  loss 
in  practice,  since  the  abstract  fairness  property  only  guarantees  that  service  will  eventually, 
after  arbitrary  finite  delay,  be  provided.  A  statement  that  says  that  at  most  a  certain 
fixed  number  of  other  events  happen  before  service  is  provided  is  much  more  useful  for  real 
application.  But  such  a  statement  of  bounded  delay  (not  in  time  but  in  terms  of  the  number 
of  observable  actions)  can  be  expressed  in  process  logic. 

One  key  question,  of  course,  is  how  properties  of  a  concurrent  program  can  be  specified  in  a 
natural  manner.  Pre-  and  postconditions  have  been  used  successfully  for  the  specification  of 
sequential  programs.  Even  though  such  techniques  use  internal  annotations  of  loops  and  local 
subprograms,  the  specifications  are  extensional.  This  is  to  say  any  program  that  satisfies 
the  prescribed  input /output  behavior  satisfies  the  specifications.  For  sequential  programs 
the  observable  behavior  is  fully  determined  by  by  the  relation  between  inputs  and  outputs 
of  the  program. 

The  process  logic  approach  uses  pre-  and  post-processes  that  express  both  the  expected  com¬ 
putation  states  as  well  as  the  communications  of  the  program  fragment  with  its  environment. 
The  description  of  the  possible  communication  behavior  must  be  exact  in  the  sense  that  it 
captures  all  possible  behaviors.  The  reason  is  compositionality:  only  if  all  possible  behaviors 
of  two  processes  are  known  is  it  possible  to  determine  their  interaction. 


1.3  Process  Logic 

In  the  following  we  give  an  informal  presentation  of  process  logic.  The  purpose  is  to  motivate 
the  choice  of  constructs  and  make  it  easier  to  follow  the  formal  definition  given  in  section  2. 

First,  the  terminology  may  need  some  clarification.  Often  the  notion  of  a  process  is  associated 
with  a  physical  (or  at  least  abstract)  agent.  Instead,  in  the  present  context  the  word  process 
refers  to  a  sequence  of  actions  being  performed.  For  example,  two  processes  performed 
concurrently  constitute  a  new  process.  The  exact  nature  of  the  agents  (e.g.  Ada  tasks)  that 
realize  a  process  is  immaterial.  Observationally,  the  execution  of  multiple  agents  constitutes 
a  single  process.  In  section  3.1  the  semantic  definition  of  Ada  tasking  will  formally  establish 
the  relation  between  a  set  of  tasks  and  their  meaning  (a  process). 
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Primitive  processes.  Complex  processes  are  constructed  from  simple  primitive  processes 
by  a  number  of  operators  that  modify  or  combine  processes.  There  are  three  primitive 
processes,  e,  6,  and  Q,.  e  is  the  terminated  process  that  will  not  perform  any  further  actions.  S 
is  the  deadlocked  process;  it  will  not  perform  any  further  actions  but  has  not  terminated.  The 
distinction  between  deadlock  and  normal  termination  is  very  important  in  the  computational 
setting.  There  is  an  observable  difference  between  the  two  processes  if  they  are  sequentially 
composed  with  another  process  (see  below).  Process  fl  indicates  the  divergent  process,  i.e.  a 
process  that  continually  performs  internal  computations  but  will  not  perform  any  observable 
action.  Depending  on  the  physical  environment,  a  deadlock  may  or  may  not  be  observably 
different  from  D.  For  instance,  a  deadlocked  program  will  appear  to  be  non-terminating  but 
the  fact  that  it  does  not  use  resources  may  be  observable. 


Actions  If  p  is  a  process,  a  -p  is  a  process  that  consists  of  performing  the  action  a  followed 
by  process  p.  Intuitively,  there  can  be  a  number  of  different  kinds  of  actions  such  as  sending 
or  receiving  a  message.  But  in  the  formalism  they  are  all  described  uniformly.  Some  actions 
require  the  cooperation  of  an  observer,  which  may  be  another  process  or  the  environment 
(e.g.  user,  physical  device  etc.).  Consider  a  very  simple  process 

PushButton?  •  LightOn!  •  e 

that  waits  for  a  button  to  be  pushed  and  will  then  turn  on  a  light  and  terminate.  There  is  a 
difference  between  the  event  PushButton?  and  the  event  LightOn!.  The  former  is  caused  by 
the  user  action  PushButton!  and  is  sensed  by  the  process,  while  the  latter  is  caused  by  the 
process  and  received  by  the  environment  as  LightOn?.  Both  actions  are  synchronous  and 
require  the  cooperation  of  two  processes  (one  of  which  may  be  the  environment). 


Alternatives  If  pi  and  p2  are  processes,  then  pi  -f  p2  is  a  process  that  can  choose  between 
Pi  and  p2.  This  choice  is  non-deterministic.  But  in  the  case  where  the  initial  actions  of  pi 
and  p2  require  cooperation,  such  as  in 

(a!  -pi)  +  (^!  •P2) 

the  behavior  of  the  process  depends  on  the  environment  (e.g.  whether  the  action  a?  or  the 
action  /??  becomes  possible  first). 


Recursion  The  processes  that  can  be  written  so  far  are  all  finite  and  not  very  interest¬ 
ing.  To  define  infinite  or  potentially  infinite  processes,  recursive  definitions  of  processes  are 
introduced.  For  instance,  a  semaphore  can  be  defined  recursively  as 

sem  PI  ■  VI  ■  sem 

This  process  accepts  an  infinite  sequence  of  alternating  P\  and  V\  operations.  Strictly 
speaking,  such  a  recursive  definition  is  merely  a  shorthand  for  recursion  operator. 
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As  a  more  realistic  example  consider  a  dish  washer.  It  has  a  door  that  can  be  opened  and 
closed,  a  start  button,  and  a  light  that  indicates  that  a  wash  cycle  is  complete.  The  dish 
washer  process  can  be  described  by 

DishWasher  ::=  close?  •  (start?  •  Cycle  +  open?  •  DishWasher) 

Cycle  (open?  •  close?  •  Cycle) 

+  (LightOn!  •  open?  •  LightOfF!  •  DishWasher) 


Internal  action  Suppose  one  wants  to  define  a  process  that  makes  a  nondeterministic 
choice  and  then  engages  in  either  action  ot\  or  action  /?!.  The  process  a!  •  e  +  /?!  •  e  does  not 
describe  such  a  process  since  its  behavior  depends  on  the  kind  of  communications  offered  by 
the  environment.  To  define  true  non-determinism  a  new  process  term  is  introduced:  r  •  p  is 
a  process  that  can  perform  some  internal  computation  and  will  then  behave  like  p.  Whether 
or  not  r  occurs  cannot  be  affected  by  the  environment.  Action  r  is  the  only  action  that  is 
not  observable. 

Consider  the  process 


Random  ::=  (r  •  a!  •  Random)  -j-  (r  •  /?!  •  Random) 

Process  Random  can  make  an  initial  choice  between  two  alternatives.  Because  either  choice 
leads  to  internal  computations,  the  choice  itself  cannot  be  influenced  by  the  environment. 
For  example,  a  faulty  dish  washer  might  be  characterized  by 

DishWasher  ::=  close?  •  (t  •  start?  •  Cycle  -f  r  •  open?  •  DishWasher) 

meaning  that,  depending  on  some  inner  non-determinism,  the  machine  allows  the  user  to 
either  push  the  start  button  or  to  open  the  door,  but  not  both. 


Value  passing  So  far,  the  language  can  describe  potentially  infinite  processes  that  engage 
in  a  finite  set  of  actions.  But  these  actions  are  atomic  and  no  data  communication  is 
associated  with  their  occurrence.  This  is  not  a  problem  in  principle  since  the  communication 
of  arbitrary  data  could  be  modeled  by  a  sequence  of  0  and  1  actions  representing  individual 
bits.  But  clearly  such  an  encoding  would  be  highly  inconvenient  for  describing  practical 
processes. 

Instead,  in  order  to  describe  communications  of  data  to  and  from  a  process,  the  notation  is 
extended  to  cdv  ■  p  and  otlx  ■  p.  Here  a  is  a  label  or  name  of  a  communication  channel.  The 
term  alv  ■  p  denotes  a  process  that  will  send  the  value  v  via  channel  a  and  will  then  behave 
like  p.  The  term  a?x  •  p  is  a  process  that  will  receive  some  value  via  channel  a  and  will  bind 
it  to  variable  x  in  p.  The  conceptual  model  is  one  where  a  send  action  is  possibly  only  when 
some  other  process  performs  a  matching  receive  action  with  the  same  label.  The  notation 
a!  •  p  and  a?  •  p  is  just  the  the  special  case  of  sending  and  receiving  an  empty  message. 
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A  simple  process  might  be 

Calc  ;:=  input?x  •  input?y  • 

(plus?  •  output!(x  +  y)  •  Calc  +  minus?  •  output!(x  —  y)  ■  Calc) 


Conditionals  Once  value  passing  can  be  described,  one  may  want  to  define  processes 
whose  future  behavior  depends  on  the  values  received.  So  far  the  language  provides  no 
mechanism  to  express  such  dependencies.  The  problem  is  addressed  by  the  following  guard 
construct:  If  p  and  q  are  processes  and  A  is  a  predicate,  then  if  A  then  p  else  qis  &  new  process, 
if  A  then  p  else  5  behaves  like  p  if  the  predicate  A  is  true  and  behaves  like  q  otherwise. 

Using  conditionals,  processes  whose  behavior  depends  on  values  received  can  be  described. 
For  example, 

p  ::=  input?x  •  if  x  mod  2  =  0  then(even!  •  p)  else(odd!  •  p) 


Extending  recursion  The  kind  of  recursive  processes  that  can  be  defined  so  far  are  cyclic 
processes  whose  behavior  is  independent  of  the  local  state,  i.e.  the  recursive  process  will 
behave  identically  for  every  cycle.  In  a  more  general  setting  one  may  want  to  describe 
cyclic  processes  whose  behavior  depends  on  some  local  state  that  may  be  different  for  every 
iteration.  This  problem  is  addressed  by  introducing  functions  from  states  to  processes  and 
allowing  recursive  definitions  of  such  functions.  For  example  a  potentially  infinite  buffer  can 
be  described  as  follows: 

6(cont)  ::=  put?x  •  6(cont&;(x)) 

+  if -'empty(cont)  then  get!fst(cont)  •  6(rest(cont))  else  6 

Here  cont  is  a  sequence  denoting  the  current  content  of  the  buffer,  (x)  denotes  a  singleton 
sequence  and  &  denotes  sequence  concatenation.  A  new  empty  buffer  process  is  given  by  the 
term  6(0).  Again,  the  notation  is  strictly  shorthand  for  a  more  complex  recursion  operator. 


Parallel  composition  The  producer  process 

p  ::=  putico  •  p 

generates  an  infinite  number  of  constants  cq.  Process  p  can  be  executed  in  parallel  with  a 
buffer  6(0).  This  new  process  is  written  as  p  \  6(()).  One  might  expect  p  \  6(())  to  be  a 
process  that  accepts  an  infinite  number  of  get  communications,  each  one  communicating  the 
value  Cq.  But  this  is  not  quite  the  case,  because  both  processes  can  still  communicate  with 
the  environment.  This  means,  for  instance,  that  p  |  6(())  can  accept  a  message  sent  to  put 
and  place  the  received  data  in  the  buffer. 
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To  be  precise  p  |  6(())  will  be  a  process  bp{{))  where 

6p(cont)  ::=  put?x  •  6p(cont  •  (x)) 

+  if-'empty(cont)  then  get!fst(coiit)  ■  6p(rest(cont))  else  5 
+  put! Co  •  6p(cont) 

+  r  •  6p(cont  •  (cq)) 

Section  2.8.1  defines  rules  for  formally  establishing  the  above  equivalence. 

It  is  important  to  guarantee  that  processes  do  not  share  state.  This  can  be  ensured  by 
the  requiring  that  two  terms  can  only  be  parallel  composed  if  their  respective  sets  of  free 
variables  are  disjoint. 


Hiding  labels  A  new  operation  is  needed  in  order  to  describe  a  process  that  has  local 
labels  that  are  not  externally  observable.  For  instance  one  may  want  to  define  a  process  just 
like  p  I  6(0)  that  does  not  engage  in  any  send  action  to  put.  Such  a  process  is  defined  by 
the  hiding  operator. 

(9{put}.(p  I  6(0)) 

a  process  that  behaves  like  p  except  that  no  communications  via 
e  H.  Applied  to  the  example  we  get  (9{put}.(p  |  6(()))  =  bp{{)) 

if-'empty(cont)thenget!fst(cont)  •  6p'(rest(cont))  else6 
+  T  •  6p'(cont  •  (co)) 

As  will  be  shown  in  section  2.8.3,  it  can  be  proved  that  bp'{{))  is  equivalent  to  a  process  r  •  g 
defined  as 

g  ::=  getlco  ■  g  +  ^ 

The  alternative  0  captures  the  fact  that  the  process  may  perform  infinite  internal  computa¬ 
tion;  i.e.,  the  process  can  perform  an  infinite  number  of  no  longer  observable  put  actions. 


In  general  dH.p  denotes 
a  are  possible  for  any  a 
where 

6p'(cont) 


Synchronization  The  communication  mechanism  introduced  so  far  suffices  to  describe 
communication  between  two  processes.  But  Ada  provides  a  mechanism  whereby  a  collec¬ 
tion  of  tasks  terminate  only  if  all  agree  to  do  so.  This  is,  in  effect,  a  form  of  multiway 
synchronization  (no  values  are  communicated). 

The  new  action  ajl'  is  a  multiway  synchronization  action.  The  term  o;ji  •  p  denotes  a  process 
that  can  synchronize  via  the  label  a  and  that  will  then  behave  like  p.  All  processes  that  are 
parallel  composed  must  synchronize.  For  example 

O'!  •  Pi  I  att  •  P2  I  •  •  •  \0iVPn 

=  att  •  (Pl  I  P2)  I  att  •  P3  I  •  •  •  I  «tl  •  Pn 


=  aS  •  (Pl  I  P2  I  •  • •  I  Pn) 
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Note  that  in  ajj  •  p  |  ^!co  ■  cx^  ■  q  the  first  process  does  not  have  the  option  to  perform  a'^- 
without  the  cooperation  of  the  second  process. 

Clearly,  one  may  want  to  limit  the  synchronization  requirement  to  a  subset  of  all  process  in 
a  system.  This  can  be  done  using  the  hiding  operator.  Hiding  is  defined  such  that 

5{a}.Q;tt  •  p  =  d{a}.p 


Quantification  Consider  again  the  buffer  process  defined  earlier 

6(cont)  put?a:  •  6(cont  •  (x)) 

+  if-'empty(cont)  then  get!fst(cont)  •  6(rest(cont))  else  6 

A  program  that  uses  a  buffer  normally  creates  a  new  instance  b[{))  as  in  the  example  p  |  b{{)). 
Suppose,  that  the  programmer  failed  to  initialize  the  buffer  content  to  the  empty  sequence. 
Then  the  new  buffer  instance  behaves  like  b(c)  for  some  random  content  c.  More  precisely, 
the  behavior  is  a  choice  6(ci)  +  f>(c2)  +  • .  •  for  all  possible  content  values  c,-.  The  new  process 
term 

Eip 

captures  this  idea.  S,p  is  the  possibly  infinite  choice  p[v\li]  +  ^[^2/*]  +  ...  for  all  possible 
values  of  i. 


Concatenation  Finally,  given  two  processes  pi  and  p2,  the  term p\\p2  denotes  the  sequen¬ 
tial  composition  of  the  two  processes,  i.e.  it  consists  of  the  behavior  of  pi  followed  by  the 
behavior  of  p2.  The  need  for  sequential  composition  stems  from  procedure  calls.  Procedural 
abstraction  may  be  used  to  encapsulate  a  sequence  of  actions.  Abstractly,  this  can  be  de¬ 
scribed  by  a  process.  Thus,  it  is  natural  to  view  procedures  as  processes  and  the  sequential 
composition  of  procedures  as  sequential  composition  of  the  respective  processes. 

On  the  other  hand,  action  prefixing  is  important  because  it  provides  a  binding  and  scoping 
mechanism.  For  example,  the  process 

{(xlx-p)-,q 

is  different  from 

alx  ■  (p-,q) 

since  in  the  former  the  binding  of  x  is  limited  to  p  while  in  the  latter  x  will  be  bound  in  p;  q. 


Equality  It  is  obvious  that  different  terms  in  process  logic  may  denote  the  “same”  process. 
Consider  the  process 

a  •  (6  •  e  -j-  6  •  c) 

which  performs  an  a  and  a  b  action  and  will  then  stop.  There  is  no  way  to  distinguish  this 
behavior  from  that  of  the  process 

a  ■  b  -  e 
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Thus,  these  two  processes  should  be  regarded  as  observationally  equivalent.  Two  processes 
should  be  considered  equal  if  they  are  observationally  equivalent.  How  can  such  and  equality 
be  defined? 

The  equality  used  in  process  logic  is  based  on  bisimulation  ([101,  87]).  The  idea  here  is  that 
two  processes  are  equivalent  (=b)  if,  in  some  intuitive  sense,  each  can  simulate  the  behavior 
of  the  other.  Bisimulation  is  formally  defined  in  section  2.6. 


Approximation  The  purpose  of  process  logic  is,  of  course,  to  use  it  for  specifying  tasking 
programs.  Suppose,  that  s  is  a  process  specification  and  p  is  a  process  that  describes  the 
actual  behavior  of  an  agent  or  program  (for  now  we  ignore  the  question  of  how  p  may  be 
determined).  We  must  define  precisely  what  it  means  for  p  to  satisfy  the  specification  s. 

One  possibility  would  be  to  say  that  a  process  p  satisfies  a  specification  s  if  p  and  s  are 
the  same  process,  i.e.,  p  =  s.  Even  though  this  is  a  reasonable  definition  it  is  not  adopted 
here.  Rather,  the  desired  relation  should  provide  some  form  of  approximation  of  fixed  points 
through  loop  invariants. 

In  section  2.8.2  the  relation  will  be  formally  defined.  For  processes  s  and  p  relation  s  p 
holds  if  p  is  bisimulation  equivalent  to  s  whenever  p  terminates.  Thus  results  in  partial 
correctness  specifications  since  s  p  is  vacuously  true  for  non-terminating  p. 


Trivial  Specifications  One  of  the  problems  with  the  definition  of  approximation  is  that 
it  is  not  possible  to  leave  the  behavior  of  a  process  unspecified.  More  formally,  there  is  no 
process  p  such  that  p  =>  ?  for  arbitrary  q.  To  address  this  problem  it  is  necessary  to  introduce 
a  new  don’t  care  process  T  with  the  property:  T  5  for  any  q.  To  see  the  utility  of  this 
construct  consider  a  program  guaranteed  to  start  in  an  initial  state  that  satisfies  A.  In  order 
to  show  that  the  program  behaves  like  process  s  it  suffices  to  specify  if  A  then  s  else  T ;  i.e.,  if 
A  does  not  hold  the  program  may  behave  arbitrarily. 


1.4  Ada  Verification 

The  previous  section  explained  on  some  intuitive  level  how  processes  and  their  behavior 
can  be  described  in  process  logic.  It  is  shown  here  how  this  logic  can  be  used  to  prove  the 
correctness  of  tasking  programs. 

One  of  the  important  features  of  process  logic  is  that  predicate  transformers  very  similar  to 
the  ones  for  sequential  programs  can  be  used  to  determine  the  process  associated  with  a  task. 
This  section  gives  an  informal  description  of  the  principles  of  using  predicate  transformers 
for  describing  the  semantics  of  tasking  programs.  A  more  detailed  definition  of  Ada  tasking 
is  presented  in  section  3.2. 
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1.4.1  Principles 

The  key  idea  is  that  a  program  will  be  annotated  with  terms  of  process  logic.  A  process 
term  placed  at  a  point  in  the  program  asserts  that  the  program,  if  started  at  this  point,  will 
behave  as  described  by  this  process.  The  process  associated  with  a  concurrent  program  can 
then  be  computed  by  a  suitable  “concurrent  predicate  transformer”  Wc.  Consider  first  the 
sequential  predicate  transformer  lTp[[S]  A  that  gives  the  weakest  liberal  precondition  ([50])  of 
program  S  under  postcondition  A.  Precondition  B  =  kFp|S]A  can  be  interpreted  as  follows; 
If  the  program  is  started  in  some  initial  state  in  which  B  holds  and  if  the  program  terminates 
it  will  satisfy  its  postcondition  (A). 

In  process  logic  the  precondition  of  S  can  be  expressed  as 

if  B  then  e  else  T 

This  says  that,  if  started  in  a  state  in  which  B  holds  and  the  program  terminates,  then 
the  program  terminates  (in  a  state  its  postcondition  A  holds)  and  otherwise  it  may  behave 
arbitrarily.  This  precondition  depends  on  the  postcondition  A  in  the  sense  that  the  postcon¬ 
dition  determines  what  should  be  considered  a  successful  termination  (e).  Note  that  this  is 
a  partial  correctness  statement:  the  precondition  makes  no  guarantee  of  termination. 

In  general,  the  process  term  if  A  then  eelse  T  corresponds  to  the  sequential  assertion  A.  Thus, 
for  sequential  program  S  the  concurrent  predicate  transformer  specializes  to 

PFcIsKif  A  then  eelse  T)  =  if(then  ITcelse|S|A)BeT. 

Now  consider  a  sequential  program  that  inputs  a  character  and  then  performs  the  same 
computation  as  S  above.  Traditionally,  such  a  program  might  be  described  by  modeling  the 
input  stream  and  by  treating  this  stream  as  a  global  variable.  In  process  logic,  the  behavior 
of  the  program  can  be  described  by  the  process 

get?c  •  if  B  then  e  else  T 

which  says  that  if  the  program  reads  a  character  c  from  event  get  and  if  then  B  is  true, 
then  it  may  terminate  in  the  desired  final  state.  Note  that  get?c  •  p  creates  a  binding  for  c 
and  the  predicate  B  my  depend  on  the  value  of  c.  Thus  preconditions  can  be  viewed  as  a 
condition  on  the  environment  in  which  the  program  is  to  be  executed  as  well  as  the  initial 
state:  the  environment  must  send  a  character  c  via  get  and  the  predicate  B  must  hold  in 
the  initial  state.  Preconditions  that  are  processes  are  referred  to  as  pre-processes.  Similarly, 
a  postcondition  that  is  a  process  is  referred  to  as  a  post-process. 

As  a  concrete  example,  consider  the  program 


declare 

integer  x; 
begin 
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get(x) ; 

if  X  <=  1  then 

put  ("error"); 
elsif  prime  (x)  then 
put  ("yes"); 

else 

put  ("no"); 
end  if; 

end; 

For  simplicity  assume  that  the  semantics  of  put  and  get  are  defined  by  channels  put  and 
get.  The  obvious  pre-process  for  post-process  t  is 

get?a:  •  if(a:  <=  0)  then 
put [“error”  •  e 
else 

if  prime(2:)  then 
put!  “yes”  •  e 
else  put!  “no”  •  e 

Note  that  the  trivial  post-process  e  is  appropriate.  The  behavior  of  the  program  is  completely 
captured  in  the  pre-process  and  the  final  state  becomes  irrelevant.  Also  note  that  this  process 
will  deadlock  if  it  is  not  executed  in  an  environment  that  will  accept  the  put  actions. 


1.4.2  Restrictions 

This  section  defines  the  subset  of  Ada  tasking  that  can  be  covered  by  our  approach  as  well 
as  the  kinds  of  properties  that  can  be  proved.  Some  of  the  restrictions  limitations  are  in 
principle  nature  while  others  have  been  stipulated  to  reduce  the  complexity  of  the  problem. 


1.4. 2.1  Termination  In  principle,  termination  is  expressible  in  process  logic  since  0  ^  e. 
This  particular  application  of  the  logic,  however,  results  in  a  partial  correctness  framework. 
The  problem  is  inherent  in  the  use  of  loop  invariant:  an  invariant  only  proves  that  a  certain 
property  is  maintained,  not  that  progress  is  made.  As  a  result,  it  is  not  possible  to  prove 
termination  properties  for  concurrent  programs.  More  generally,  it  will  be  possible  to  prove 
safety  properties  but  not  liveness  properties. 

In  principle,  process  logic  would  not  require  invariants  since  weakest  pre-processes  of  loops 
are  expressible.  For  instance,  the  program 

while  X  /=  0  loop  x  :=  x  -  1;  end  loop; 

with  post-process  e  has  the  pre-process  p{x)  where 

p{y)  ::=  if  y  ^  Othen  p{y  —  1)  else  e 
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which  can  be  shown  to  be  equal  to  (see  section  2.8.3) 

if  a:  >  Othen  eelsefi 

This  means  that  the  program  will  behave  like  e  if  a;  >  0  and  will  diverge  otherwise. 

When  using  invariants  to  reason  about  this  loop,  it  is  possible  to  pick  the  invariant  e.  This 
leads  to  the  verification  condition 

e  =1^  if x  0 then  e[a;  —  Ijx]  else  e 

or  e  e  and  the  pre-process  e.  This  is  a  reasonable  statement  in  a  partial  correctness 
setting  and  it  is  sound  since  the  pre-process  e  is  stronger  than  the  weakest  pre-process 
ifa;  >  Otheneelsef],  i.e. 

e  =>  if  a:  >  0  then  e  else  0 


1.4. 2. 2  Timing  As  an  obvious  consequence  of  the  above  restriction  it  will  not  be  possible 
to  reason  about  time.  Reasoning  about  the  timing  behavior  of  concurrent  programs  is  even 
more  complex  than  reasoning  about  termination.  An  adequate  description  of  timing  requires 
assumptions  about  the  speed  of  execution  of  an  Ada  program  and  needs  to  consider  program 
optimizations,  processor  speeds,  operating  system  scheduling,  and  other  factors.  The  present 
approach  treats  delay  statements  as  if  they  had  zero  delay.  Similar  treatment  applies  to 
selective  waits  and  timed  entry  calls. 


1.4. 2. 3  Priorities  In  order  to  deal  with  priorities,  the  formal  model  needs  to  be  ex¬ 
tended.  There  has  been  some  work  (e.g.  [32]  and  [63])  on  adding  priorities  to  process  al¬ 
gebra.  But  in  addition,  the  definition  of  priorities  requires  that  entry  queues  be  modeled 
explicitly  in  the  semantics  (see  3.2.4).  For  instance,  problems  such  as  priority  inversion  must 
be  captured  by  any  semantics  that  deals  with  priorities. 


1.4. 2. 4  Task  Status  The  given  semantics  of  tasks  is  abstract  in  the  sense  that  it  does  not 
model  certain  implementation  notions.  Concepts  such  as  the  status  of  a  task  (e.g.  whether 
the  task  is  active  or  terminated)  as  well  as  explicit  entry  queues  are  not  modeled  by  our 
semantics.  As  a  result,  it  is  not  possible  to  reason  about  the  following  attributes: 

T’CALLABLE 

T’COUNT 

T’TERMINATED 

1.4. 2. 5  Abort  statement  The  current  form  of  process  logic  cannot  describe  abort  state¬ 
ments  properly.  Aborting  a  task  is  a  form  of  communication  that  affects  two  processes  but 
does  not  require  the  cooperation  of  both.  Such  a  mechanism  is  currently  not  provided  (see 
3.2.9). 
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1.4. 2. 6  Entry  queues  The  semantics  does  not  model  Ada’s  entry  queues.  Consequently, 
the  ’LENGTH  attribute  cannot  be  handled.  Similarly,  the  semantics  of  a  conditional  entry 
call  is  simple  a  nondeterministic  choice  between  the  call  and  the  else  clause. 

Omitting  entry  queues  form  the  model  affords  a  significant  simplification  of  the  definition 
and  of  program  proofs.  This  omission  is  not  a  serious  limitation  since  in  the  absence  of 
priorities  the  effect  of  entry  queues  is  not  observable. 


1.4. 2. 7  Global  variables  Global  variables  can  always  be  modeled  as  new  processes  that 
allow  only  two  communications:  reading  and  writing.  This  is  a  trivial  syntactic  transforma¬ 
tion  and  it  is  assumed  that  the  abstract  program  representation  has  been  transformed  to 
represent  access  to  shared  variables  by  explicit  read  and  write  operations.  A  semantics  of 
these  operations  is  given  in  process  logic. 


1.5  Related  Work 
1.5.1  Process  Algebra 

The  specification  language  described  here  is  based  on  process  algebra.  Process  algebra  has 
its  roots  in  Milner’s  CCS  ([87])  and  Hoare’s  CSP  ([57]).  Later  work  includes  ATP  ([53]) 
and  AGP  ([15,  18,  19]).  The  relevance  of  ATP  is  that  it  avoids  the  use  of  internal  actions 
and  uses  two  different  choice  operators  instead.  Bergstra  and  Klop  [18]  provide  a  confluent 
rewrite  system  for  AGP.  Some  of  the  axiomatization  in  our  approach  is  based  on  their  ideas. 

Process  algebra  is  a  very  active  field  of  research.  Current  work  in  the  area  ranges  from 
theoretical  foundations  to  practical  applications. 

Theoretical  work  in  the  area  is  concerned  with  model  construction  and  extending  the  algebra 
to  value  passing  ([59]).  Also,  there  have  been  attempts  to  define  higher-order  process  algebras 
(e.g.  [117, 118])  where  processes  are  themselves  values  that  can  be  passed  as  arguments.  Even 
though  Ada  provides  task  types,  and  thus  first-class  tasks,  this  generality  was  not  necessary 
to  deal  with  Ada  semantics. 

Process  algebra  has  the  advantage  over  other  approaches  to  concurrency  semantics  that 
it  provides  process  abstractions  with  elegant  mathematical  properties.  This  will  greatly 
simplify  the  task  of  specifying  concurrent  systems  and  reasoning  about  their  properties.  As 
is  pointed  out  in  [69]  process  algebra  is  suitable  for  implementation  through  transformation 
and  can  be  used  for  prototyping  by  constructing  interpreters. 

The  disadvantage  of  process  algebra  is  that  it  cannot  describe  fairness  and  it  is  cumbersome 
to  define  shared  memory.  While  it  is  possible  to  augment  process  algebra  with  priorities  (see 
[32])  we  chose  to  avoid  this  complication. 

Properties  of  processes  can  be  characterized  by  modal  formulas  (Hennessy-Milner  logic  [55]). 
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Here  events  of  the  process  correspond  to  modal  operators.  Thus  is  is  possible  to  state  that 
certain  events  alwarjs  or  sometimes  follow  other  events. 

There  are  a  number  of  applications  of  process  algebra.  The  following  are  just  a  few.  The 
programming  language  Occam  ([61])  provides  built-in  concurrency  primitives  that  direct 
modeled  after  CSP.  The  language  is  actively  used  in  production  work.  The  formal  speci¬ 
fication  languages  LOTOS  ([22])  and  RSL  ([44])  are  based  on  process  algebra  (see  section 
1.5.3).  Process  algebra  has  been  used  to  specify  and  prove  correct  systolic  algorithms  (e.g., 
[54])  and  protocols  (e.g.,  [120],  [73]).  Additional  application  can  be  found  in  [14]. 

Another  approach  to  defining  the  semantics  of  Ada  tasking  is  taken  by  Astesiano  and  Reggio 
based  on  SMoLCS  ([12]).  SMoLCS  takes  a  two  step  approach.  First,  a  denotational  style 
definition  maps  programs  into  an  intermediate  language  that  contains  concurrency  primi¬ 
tives.  The  concurrency  is  defined  in  terms  of  a  parameterized  labeled  transition  system  that 
has  its  roots  in  CCS  ([87])  and  SCCS  ([89]).  Properties  of  the  transition  relation  are  defined 
algebraically. 


1.5.2  Other  Approaches 


1.5. 2.1  Modal  logic  First-order  logic  can  be  enriched  with  modal  operators  such  as 
“always”,  written  □,  and  “eventually”,  written  O.  Examples  of  sentences  in  modal  logic  are 
□p  (proposition  p  is  always  true)  and  Op  (proposition  p  will  be  eventually  true).  Appropriate 
deduction  rules  and  axioms  can  be  defined  for  modal  logic.  For  example,  (Dp)  =>•  (Op)  holds, 
as  does  (Dp)  -’(0--p). 


Modal  logic^  has  a  number  of  application  in  semantics  and  verification.  The  typical  way 
to  use  modal  logic  to  describe  concurrent  programs  uses  an  enriched  program  state  that 
contains  the  current  locus  of  control.  It  is  thus  possible  to  write  control  predicates  that  state 
that  a  particular  statement  is  about  to  be  executed.  For  example,  the  predicate  @l  holds 
when  control  is  “now”  at  label  1.  Using  control  predicates  one  can  write  modal  statements 
like 


{@li  A  p)  0(@/2  A  q) 


This  says  that  if  control  is  at  label  li  and  if  proposition  p  is  true,  then  eventually  control 
will  reach  label  I2  and  proposition  q  will  be  true.  See  [72]  for  an  example  of  the  use  of  modal 
logic  to  reason  about  concurrent  programs. 


One  difficulty  with  modal  reasoning  and  the  used  of  control  predicates  is  that  the  technique 
is  not  compositional.  This  means,  that  one  cannot  specify  and  reason  about  components 
separately  and  later  draw  conclusions  about  their  composition.  As  a  result,  the  technique 
does  not  support  abstraction.  Also,  the  use  of  control  predicates  is  appropriate  for  reasoning 
about  sequences  of  computation  states.  Process  algebra  abstracts  from  the  state  and  con¬ 
siders  the  sequences  of  observable  actions  (that  cause  state  changes).  Hennessy-Milner  logic 

^In  the  context  of  concurrency  many  authors  use  the  term  temporal  logic 
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([55])  is  a  modal  logic  for  reasoning  about  processes.  In  essence,  a  process  is  viewed  as  an 
abstract  program  that  executes  observable  actions. 


Statements  of  a  programming  language  can  themselves  be  viewed  as  modal  operators.  The 
]p  means  “after  execution  of  S  proposition  p  holds”.  This  is  to  say  that  [s]p  is 


sentence 


the  precondition  of  S  for  post-process  p.  This  view  is  discussed  extensively  in  the  literature 
on  dynamic  logic  ([52]). 


1.5. 2. 2  Axiomatic  Methods  The  first  approaches  to  formally  deal  with  concurrency 
were  developed  as  extensions  to  axiomatic  proof  techniques  for  sequential  programs.  Lam¬ 
port’s  version  of  concurrent  Hoare  logic  ([71])  uses  control  predicates.  Other  approaches  are 
closer  to  the  original  Hoare  method  and  consider  conditions  under  which  parallel  composition 
of  program  parts  is  well  defined. 

One  such  methods  of  reasoning  about  concurrent  programs  was  developed  by  Owicki,  Cries 
([100]).  Their  method  is  an  extension  of  Hoare  logic  based  on  the  concept  of  mutual  non¬ 
interference.  Given  two  statements  SI  and  S2  that  are  executed  in  parallel,  then  the  rule 

{Pi}S1{Qi},{P2}S2{Q2} 

{Pi  a  P2}  SI  II  S2  {Qi  A  Q2} 

is  valid  if  SI  and  S2  do  not  interfere.  The  notion  of  interference  can  be  defined  more  precisely 
in  terms  of  variables  read  and  written  by  concurrent  program  parts  (see  [100]). 

Similar  to  the  non-interference  test,  de  Roever  introduced  a  proof  technique  based  on  the 
“cooperation  test”  ([46]).  This  technique  is  baised  on  conventional  annotation  with  input 
output  conditions.  For  a  communication  action  e,  the  proof  of  an  individual  process  may 
assume  a  particular  behavior,  e.g.  {p}e{q}.  Based  on  such  assumptions  the  partial  correct¬ 
ness  of  a  single  process  is  established.  In  order  to  combine  several  processes,  it  is  necessary 
to  show  that  the  individual  proofs  cooperate.  This  means  that  if  was  assumed  in 

the  proof  of  one  process,  then  the  proofs  of  all  other  processes  must  be  based  on  the  same 
assumptions  about  e.  The  basic  method  is  refined  by  introducing  a  global  invariant.  Using 
this  invariant  it  is  possible  to  reason  about  values  being  communicated  and  properties  of  the 
combined  program.  The  global  invariant  may  be  assumed  in  the  proof  of  individual  program 
parts  but  it  must  also  be  shown  that  all  program  parts  preserve  the  invariant.  Consequently, 
the  individual  proofs  depend  on  the  global  invariant  and  the  technique  is  not  compositional. 

In  [45]  Gerth  defines  the  semantics  of  the  Ada  rendezvous  using  the  cooperation  test. 


1.5. 2. 3  History  Sequences  Various  researchers  have  used  history  sequences  to  given 
an  axiomatic  semantics  of  concurrency.  The  core  idea  of  this  approach  can  be  summarized 
as  follows. 

Communication  is  described  by  a  history  of  communication  events.  Within  one  process  a 
local,  unshared  history  variable  h  is  assumed.  The  semantics  of  passing  a  message  to  another 
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process  is  described  by  appending  a  send  action  to  h.  Receiving  a  message  is  modeled  by 
appending  a  receive  action  h. 

Given  statements  SI  and  S2  that  communicate  only  by  message  passing,  we  have  the  following 
proof  rule 

{P,Ah  =  ()}  SI  {Q,Ah  =  //jsi},  {P2Ah  =  ()}  S2  {Q2Ah  = 

{Pi  A  P2}  SI  II  S2  {giAg2} 

Here  H  is  the  assumed  global  history  of  both  processes.  Hlsi  is  the  projection  of  the  global 
history  H  onto  the  event  sequence  as  seen  by  SI.  The  rule  can  be  read  as  follows:  If  there 
is  a  global  history  H  such  that  the  messages  sent  by  SI  are  the  message  received  by  S2  and 
vice  versa,  then  the  two  statements  and  be  executed  in  parallel  with  the  combined  effect  on 
the  state.  A  description  of  this  technique  can  be  found  in  [116]  and  [80]. 


1.5.3  Other  Specification  Languages 

Process  algebra  is  the  basis  for  the  development  of  other  concurrency  specification  languages. 
LOTOS  and  RSL  are  two  important  examples  since  both  are  concerned  with  specifications 
of  real  systems  and  go  beyond  the  realm  of  academic  exercises. 


1.5. 3.1  LOTOS  LOTOS  (Language  of  Temporal  Ordering  Specification)  is  a  specifica¬ 
tion  language  based  on  process  algebra.  It  was  designed  specifically  to  specify  distributed 
systems  and  protocols.  Standardization  of  the  language  by  ISO  is  underway. 

LOTOS  is  very  similar  to  process  logic.  The  following  are  some  of  the  similarities  between 
the  two  systems: 

1.  The  syntax  and  semantics  of  value  passing  are  virtually  identical.  The  main  difference 
is  that  in  LOTOS  binding  occurrences  of  variables  are  explicitly  typed. 

2.  The  conditional  of  process  logic  corresponds  to  boolean  guards  in  LOTOS. 

3.  The  infinite  sum  (S)  corresponds  to  the  LOTOS  choice  operator. 

4.  LOTOS  synchronization  gates  provide  a  way  to  express  synchronization  between  multi¬ 
ple  processes  similar  to  the  synchronization  events  in  process  logic.  The  key  difference 
is  that  LOTOS  specifies  synchronization  gates  as  part  of  a  special  parallel  composition 
operator  while  process  logic  uses  a  special  kind  of  event  to  indicate  synchronization. 


One  important  feature  of  LOTOS,  not  present  in  process  logic,  is  the  disabling  operator.  In 
effect  p[>  q  is  a,  process  that  behaves  like  p  until  q  makes  a  transition.  From  this  point  on 
only  q  transitions  are  possible.  Transitions  of  p  are  disabled.  This  construct  is  very  useful 
in  defining  the  semantics  of  the  Ada  abort  statement.  A  similar  construct  is  not  included  in 
process  logic  since  its  formal  basis  is  not  fully  understood. 
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In  addition  to  process  specifications  LOTOS  includes  a  sublanguage  for  the  specification  of 
abstract  data  types  (ACT  ONE  [41]).  In  contrast,  process  logic  only  assumes  some  first- 
order  language.  The  details  of  this  language  are  left  unspecified.  In  the  case  of  Penelope,  of 
course,  the  underlying  first-order  language  is  the  Larch  shared  language. 


1.5. 3. 2  RSL  The  RAISE  project  (Rigorous  Approach  to  Industrial  Software  Engineer¬ 
ing)  was  part  of  the  European  ESPRIT  effort  and  involved  participants  from  industry  and 
academia.  The  team  developed  the  RAISE  specification  language  (RSL)  for  formally  specify¬ 
ing  software  systems  ([44]).  RSL  employs  CLEAR-style  algebraic  definitions  of  abstract  data 
types  and  uses  CSP/CCS-style  specifications  of  concurrency.  In  RSL  processes  are  typed 
according  to  the  channels  (events)  through  which  they  can  communicate.  The  concurrency 
constructs  are  very  similar  to  those  used  in  process  logic.  The  main  semantic  differences 
are  the  use  of  internal  and  external  choice  operators  (similar  to  ATP  [53])  and  the  use  of 
stop  to  denote  both  normal  termination  and  deadlock.  Using  both  internal  and  external 
choice  operators  avoids  the  need  for  internal  actions.  Internal  actions  are  mathematically 
more  difficult  to  describe.  But  they  are  closer  to  the  user’s  computational  model  and  may 
therefore  be  easier  to  understand.  The  inability  of  RSL  to  distinguish  deadlock  from  normal 
termination  is  a  serious  problem. 

The  following  is  a  RSL  specification  of  a  buffer  process. 

buffer(6)  =  empty?;  buffer(()) 

[] 

let  V  =  add?  in  buffer(6&:())  end 

0 

if  6  ^  0  then  get!  (first  (6));  buffer  (rest  (6))  else  stop  end 
The  corresponding  specification  in  process  logic  differs  only  in  the  syntax: 

buffer(6)  :=  empty?  •  buffer(())  (1) 

-f  add?u  •  buffer(6&;())  (2) 

-f-  if  6  /  0  then  get!first(6)  •  else(^  (3) 


1.5.4  Support  Tools 

Several  research  projects  are  in  the  stage  of  tool  development  including  analysis  tools  and 
special  purpose  theorem  provers.  It  can  be  expected  that  some  of  these  tools  will  become 
usable  and  available  in  the  near  term.  There  are  two  classes  of  theorem  provers,  those  based 
on  a  model-checking  approach  and  those  based  on  an  inference  system.  Working  systems 
of  the  former  class  are  AUTO  ([24]),  Squiggle  ([23]),  and  Workbench  ([33]).  One  version  of 
the  workbench  has  extended  to  include  priorities  ([63]).  Examples  of  the  second  class  are 
CRLAB  ([97])  and  PSF  ([81]).  A  comparison  of  these  and  other  tools  can  be  found  in  [60]. 
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Another  tool  for  reasoning  about  process  algebra  is  PAM  (Process  Algebra  Manipulator, 
[77]).  PAM  implements  a  general  rewrite  engine  and  mechanisms  for  various  forms  of  in¬ 
ductions.  The  system  can  be  configured  for  different  process  algebra  formalisms  by  defining 
suitable  equations  (rewrite  rules). 

Process  algebra  can  be  expressed  in  HOL  ([48])  and  the  HOL  prover  has  been  used  to  show 
bisimulation  equivalence  of  process  terms  ([96]). 


1.6  Organization 

The  following  section  contains  a  rigorous  description  of  process  logic  including  its  syntax, 
semantics,  and  proof  theory.  Section  3  describes  the  application  of  process  logic  to  specify  the 
semantics  of  Ada  and  ways  to  specify  and  verify  concurrent  programs.  Only  the  principles 
are  discussed  here  and  this  section  does  not  constitute  a  complete  formal  definition  of  Ada 
tasking  semantics. 

In  section  4  process  logic  is  applied  in  several  examples.  This  illustrates  techniques  for  the 
systematic  development  of  tasking  programs,  strategies  for  developing  annotations,  and  proof 
techniques.  The  examples  point  out  area^  where  the  basic  mechanisms  need  to  be  extended 
by  more  abstract  specification  concepts  in  order  to  become  practical. 


2  Formal  Basis 
2.1  Notation 

Lambda  notation  has  its  usual  meaning,  e.g.  Xx.fxx.  Type  information  is  omitted  where 
it  can  be  inferred.  Sometimes  function  application  is  written  as  juxtaposition,  e.g.  fx. 
Functions  may  be  curried.  Functions  can  be  redefined  point-wise  as 

f[d  ^  e]  =  Ax.  ifx  =  dthen  eelse/  x 

Substitution  of  x  for  y  in  t  is  written  a.s  p[x/y].  The  notation  for  parallel  substitution  is 

p[xi/yi,...,xn/yn]- 


2.2  Domains 

Definition  1  A  domain  is  a  set  D  with  a  partial  order  C  such  that 

1.  A.  £  D  and  L  Q  d  for  all  d  E  D. 

2.  Every  C  chain  has  a  least  upper  hound. 

3.  There  is  a  countable  base  Db  Q  D  such  that  every  d  e  D  is  the  least  upper  bound  of 
some  Db  chain. 
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The  importance  of  domains  is  that  equations  involving  +  (sum),  x  (product),  and  — >  (con¬ 
tinuous  function)  constructors  have  solutions  in  domains.  Further,  continuous  functions  on 
domains  have  unique  least  fixed  points.  A  more  detailed  discussion  of  domains  can  be  found 
in  [51]. 

Describing  concurrent  and  non-deterministic  programs  requires  powerdomains.  I.e.,  a  con¬ 
structor  P  is  needed  that  constructs  the  domain  of  subsets  of  a  given  domain.  It  is  then 
possible  to  solve  domain  equation  involving  P  (see  e.g.  [51,  78,  79]). 

One  powerdomain  construction  due  to  Symth  ([113])  defines  I*siD)  is  defined  as 

Ps{D)  =  {S  C  D\S  is  non-empty  and  finite  or  TG  5} 

An  ordering  (Egli-Milner)  C  on  P5(D)  is  defined  as  follows 

„  ^  „  _  /  Vs  G  S.3t  eT.sQt 
T3s  eS.sOt 

One  problem  with  this  construction  is  that  Ps{D)  does  not  contain  the  empty  set. 

The  powerdomain  construction  proposed  by  Plotkin  [103]  does  not  suffer  this  problem  and 
the  following  is  based  on  Plotkin  powerdomains.  Abramsky  shows  in  [2]  how  to  extend  the 
latter  to  a  constructor  P°  that  generates  a  powerdomain  that  contains  the  empty  set. 

For  the  details  of  the  P°  construction  see  [2].  Here  only  the  following  properties  are  of 
interest. 


•  P°  is  a  functor,  i.e.,  it  maps  a  function  /  G  >  T>2  to  a  function  P°/  G  P°(Di) 

P°{D2). 

•  Further,  the  following  operations  are  defined: 


MeP°(Z)) 

UeD-^p%D) 

y  G  P°(D)  P°(D)  P°(T)) 

li)  G  P°(P°(D))  ^  P°(D) 


Empty  set 
Singleton  set 
Union 
Join 


Using  the  construction  given  in  [2]  it  can  be  shown  that  (P°,  -fl-Djli))  is  a  monad  as  defined 
in  [121].  Following  Wadler  ([121])  P°  is  a  “monad  with  zero”  (Ax. ■{][})  and  therefore  admits 
comprehension  with  filters.  Thus,  terms  such  as 

{j/x  1  X  G  X,px^  G  P°{D2) 

for  X  G  P°{Di)  and  continuous  /  G  — >  ZJ2  and  predicate  p  has  meaning  as  defined  in 

[121]: 

^t\xex^  =  p°{Xx.t)x 
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|a:GX,..4  =  ]SUt\  ...[[  beXfr 
{|t  I  pj}  =  ifpthen^l^elsejlj} 

■gt  |p,...i}  =  \SUi\  ••■1}  lp|} 

=  if p then  |  •  H  else|l} 

For  example,  the  term  -{j/x  |  x  €  A',px[}  expands  as  follows 

^fx\xeX,px^  =  yilt  I  px^  I  X  G  X[[ 

=  yi  ifpxthen{]t|}  else-fll}  I  X  G  A^l} 
=  y(P°(Ax.  ifpxthen-{]i|}  else{]|})A') 


2.3  First-order  Logic 

Terms  of  process  logic  will  contain  terms  and  formulas  of  some  first-order  language  C  defined 
as  follows^: 

The  syntax  is  defined  as  follows: 

A,B^  Fred  Predicate  Symbols 
/,  p  G  Func  Function  Symbols 

c  G  Const  Constants 

x,u  G  Far  Variables 

t  G  Term  Terms 

A  G  Form  Formulas 

where 

t  V  I  c  I  f  (ti  1  •  •  •  1  tO 

A  ::=  =  ^2  I  F{ti, . . . ,  t„)  |  false  [  Ai  — >  A2  |  Vx.A  |  . . . 

The  usual  set  of  boolean  connectives  and  existential  quantifiers  will  be  used;  they  can  be 
defined  from  the  above  in  the  obvious  way. 

An  £-Structure  Af  =  {D,I)  consists  of  a  domain  D  and  an  interpretation  I  such  that 

1-  t{F)  C  £)"■  for  n-ary  predicate  F 
2.  I{f)  E  D  for  n-ary  function  / 

^Very  little  changes  if  a  different  logic  is  substituted  in  the  definition  of  process  logic 
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3.  /(c)  €  D  for  every  constant. 

A  A/- valuation  i/  ^  V  =  Var  — >  D  assigns  a  value  in  D  to  every  variable  of  £.  Every  u  £  V 
extends  to  all  terms  in  the  obvious  way,  we  write  p{t)  to  denote  the  value  of  term  t  under 
valuation  u. 

We  write 

W  1=1/  A 

if  the  formula  A  is  true  under  the  valuation  v.  M  \=  A  says  that  A  is  true  in  Af  under  all 
valuations.  Equivalently,  the  notation  /V”|AJi/  is  used  to  denote  the  truth  of  Af  \=u  A. 


2.4  Processes 

For  (first-order)  language  C  the  language  of  processes  /^(/l)  is  defined  as  follows^. 

o,  /3  €  Lab  Labels  (or  channels) 

H  C  Lab  Subset  of  labels 

p, q  E  Proc  Processes 

P,Q  E  Pfun  Process  functions 

f,gE  Pvar  Function  symbols 

A  and  t  refer  to  formulas  and  terms  of  C  respectively. 

P  ::=  Xx.p  I  /  I  pf.P 

p  (5  I  e  I  n  I  r  •  p  I  if  A  then  p  else  ^  |  dH.p  \ 

aji  •  p  I  a!t  •  p  I  alx  •p|p  +  9|p|9|p;9|  ^xevp 

Processes  distinguish  deadlock  (6^)  and  normal  termination  (e).  The  treatment  is  similar  to 
AGP  [15]  in  that  p  +  ^  =  p  holds  for  all  p.  This  differs  from  the  treatment  in  [5]  where 
p  +  e  =  p  holds  instead. 

AGP  uses  concatenation  (“;”)  as  the  basic  process  constructors  and  GGS  based  systems  use 
action  prefixing  (“■”)•  Process  logic  contains  both  constructs.  Action  prefixing  is  appropriate 
for  receive  actions  since  they  are  binding  operations;  the  process  following  a  receive  action 
is  the  scope  of  the  received  value.  On  the  other  hand,  process  concatenation  turns  out  to 
needed  for  the  semantics  of  a  procedure  calls. 

'‘The  syntax  has  been  changed  drastically  from  earlier  versions.  The  main  reason  is  to  be  consistent  with 
other  work  in  the  area.  The  original  notation  was  heavily  influenced  by  a  modal  logic  approach.  The  present 
notation  hzis  its  roots  in  AGP,  CCS,  ECS. 
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The  introduction  of  sequential  composition  leads  to  context  free  processes,  i.e.,  a  language 
that  (in  the  absence  of  value  passing)  is  strictly  more  powerfull  than  one  that  only  uses 
action  prefixing.  For  instance, 

p  ::=  (a  •  p;  6  ■  e)  +  e 

is  a  process  that  generates  the  context  free  language  of  actions  a" 6”  which  cannot  be  defined 
with  action  prefixing  alone  since  this  defines  only  regular  languages.  Note,  however,  that  by 
introducing  auxiliary  state  variables  we  can  define 

p  ::=  Pi(0) 

pi(ra)  a  •  pi(n  +  1)  +  P2(n) 

P2(n)  if  n  =  0  then  e  else  6  •  p2(ra  —  1) 


The  notation  is  used  to  denote  the  (possibly  infinite)  choice  over  all  values  Xi  G  X , 

p[a;i/x]  +  p[x2/a:]  +  .  ■  ■  We  write  E^p  if  the  domain  of  x  is  clear  from  the  context. 

Constructs  for  sending  and  receiving  values  were  originally  proposed  by  Milne  and  Milner  in 
[83].  More  recently,  a  variation  was  proposed  in  [59]. 

Because  of  the  presence  of  value  passing  and  the  conditional  construct,  the  behavior  of  a 
process  depends  on  the  state.  And  the  definition  of  recursive  processes  needs  to  account  for 
changing  state.  For  this  reason  the  syntax  contains  general  process  functions,  i.e.,  functions 
from  values  to  processes  and  a  least  fixed  point  construct  p  for  such  functions.  The  notational 
shorthand  /(x)  ::=  p  is  used  to  make  recursive  processes  more  readable.  The  term  /(t)  means 
(p/.Ax.p)(t)  in  the  context  of  a  definition  /(x)  p.  Special  care  is  needed  in  manipulating 
formulas  that  used  this  abbreviated  notation.  For  instance  f{t)[e/y]  =  /(t)  is  generally  false 
even  if  y  is  not  free  in  t  since  it  may  be  free  in  the  definitional  equation  of  /. 


2.5  Operational  Semantics 

An  operational  semantics  of  process  logic  can  be  given  as  a  labeled  transition  system.  Let 
A  be  the  set  of  actions  defined  as  follows; 

T  represents  an  internal  computation, 
a\v  represents  the  sending  of  value  v  via  event  a, 
a?u  represents  the  reception  of  value  v  via  event  a,  and 
a]]  represents  the  synchronization  with  event  a. 

Function  lab  e  A Lab  Li  {r}  determines  the  label  of  an  action: 

lab{T)  =  r 
lab{a\v)  =  a 
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lab(a‘lv)  =  a 
lab{a^)  =  a 


For  a  E  A  we  write  a  •  p  for  the  process  that  performs  a  and  then  behaves  like  p. 

A  labeled  transition  system  is  a  relation  Proc  x  A  x  Proc.  If  a  triple  (p,  a,  q)  we 
write  p  q.  By  convention  a  E  A  is  any  action,  p  q  means  that  the  process  p  can 
perform  the  action  a  and  transition  to  process  q. 

Note  that  the  possible  transitions  for  process  p  depend  on  the  state  (i.e.,  the  values  of  the 
free  variables  of  p).  Thus  the  following  definitions  assume  an  arbitrary  but  fixed  /^-structure 
J\f  and  A/"-valuation  u.  More  pedantically,  one  might  write  J\f  \=i,  p  q,  meaning  that  in  a 
state  u  process  p  can  perform  a  and  then  behave  like  q. 

alt  •  p  ^  p  a‘?x  •  p  ^  p[t/x] 


T  •  pA^  p 


U  “ll 
ajj  •  p 


p-^  q 

p  +  r  q 


a 

p^  q 

r  p^A  q 


p[c/x]  q 

SiP'^  q 


p  q,  lab{a)  ^  H 

p^  q,  dH.q  r,  a  ^  H 

dH.p  dH.q 

dH.p  r 

P'^  q,  B 

P'^  q,  ~'B 

if  5thenpelser  q 

Note  that  B  refers  to  the  truth  of  B  is  the 

if  B  then  r  elsep  q 

given  valuation  i/. 

P'^  q,  a  7^  a|J 

P'^  q,  a  / 

ajt 

(r  1  p)  (r  1  q) 

(p  1  r)  [q 

1 

alt  /  ait  ! 

p  q,  p  g 

all  ,  ai 

p  p  ,  q 

q' 

p  p'-^  q\q 

(p  1  p')  4  {q  1 

q') 
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q 


p\r  q\r 


a 

P'^  q 
e-,p^  q 


P[pf.P/f]{t)^q  p[t/x]'^q 

pf.P{t)  q  (Ax.p)(i)  q 


The  relation  can  be  extended  to  sequences  of  actions  in  the  obvious  way.  In  particular, 
we  write 

p  ^  q  \u.  p  p  q  q 

i.e.,  if  there  are  zero  or  more  internal  transitions  and  an  a  transition  that  transform  p  into 
q.  Similarly, 

-a-  {  q  when  a  ^  r 

p-^  q  in  < 

[  p^  qor  p  =  q  when  a  =  r 

includes  the  reflexive  case  p^  p. 

The  unary  relation  C  Proc  defines  terminated  processes.  A  process  is  in  if  it  cannot 
perform  any  further  actions  but  is  not  deadlocked.  Instead  of  p  €  we  write  p^/ .  Again, 
the  following  definitions  assume  some  fixed  valuation  v.  is  the  smallest  relation  such  that 


eV" 

p-v/  implies 
P\/)  q\/  implies 
Vc.(p[c/x]a/)  implies 
p-y/,  B  implies 
p-y/,  -iR  implies 
P[^/^W  implies 
P[pf.P/f]{t)^/  implies 


{dH.pW 

ip  +  q)y/Ap  I  q)VAp><i)V 

(Sxp)V' 

(if  5  then  p  else  q)^/ 

(if  5  then  q  elsep)^/ 
{Xx.p){t)y/ 

{pf-pmv 


Similarly,  |C  Prods  the  relation  defining  definite  processes,  i.e.,  those  processes  that  do  not 
diverge  without  performing  any  action.  Again,  p  €j.  is  written  p  J,  and  p  J,  means  that  p  | 
for  all  valuations  in  which  A  is  true.  I  is  the  smallest  relation  such  that 


e  i 

n 

a  •  p  i 

P  i 

implies 

(dH.p)  i 

P  i 

implies 

(p;  q)  i 

pV^q  i 

implies 

(p;  q)  i 

p  i,q  i 

implies 

ip  +  q)  i 

and  (p  1  7)  i 
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Vc.(p[c/x]  I)  implies 
p  i,B  implies 
p  I,  ->B  implies 
p[t/x]  I  implies 
i  implies 


(S.p)  i 

(if  B  then  p  else  q)  J, 
(if  j5  then  5  else  p)  | 
(Aa;.p)(^)  i 

if^i-pm  I 


Next,  JJ-C  Proc  is  the  set  of  definite  processes  that  cannot  perform  an  infinite  sequence  of  r 
actions.  Formally  (J.  is  the  smallest  relations  such  that 

p  ^  if  (pi  A(V9.p-^  g  g  ^)) 


Finally,  V  C  Proc  is  the  set  of  processes  that  will  not  deadlock  before  performing  a  non- 
r  action,  i.e.  pV  if  any  state  q  reachable  through  r  transitions  from  which  not  further  r 
transitions  are  possible  will  be  a  terminated  state,  formally 

pV  iff  (Vg.p-^  q  A  -'3q'.q  ^  q'  q^/j 


2.6  Process  Equivalence 

Obviously,  two  different  process  terras  can  denote  two  processes  that  are  not  observably 
different.  The  key  question  is  what  me  mean  by  “observable”.  There  are  a  number  of 
different  equivalence  relations  proposed  in  the  literature.  Bisimulation  ([101])  appears  to  be 
the  most  natural  definition.  The  definition  says  that  two  processes  are  equivalent  if  any  action 
that  can  be  performed  by  one  can  be  performed  by  the  other  such  that  the  resulting  new 
processes  are  equivalent.  The  literature  distinguishes  between  weak  and  strong  bisimulation. 
The  difference  is  that  weak  bisimulation  aissumes  that  the  performance  of  an  internal  action 
is  not  observable. 

One  strong  argument  in  favor  of  bisimulation  is  the  modal  characterization  theorem.  The 
theorem  says  that  two  processes  are  bisimulation  equivalent  if  and  only  if  they  satisfy  the 
same  sets  of  formulas  in  Hennessy-Milner  logic. 

A  different  process  equivalence,  called  branching  bisimulation,  has  been  proposed  ([47]). 
Branching  bisimulation  is  a  smaller  relation  than  bisimulation,  i.e.,  there  are  processes  that 
are  distinguished  by  branching  bisimulation  but  that  are  weakly  bisimilar.  Branching  bisim¬ 
ulation  provides  a  reasonable  definition  of  process  equivalence  since,  as  for  weak  bisimulation, 
there  is  a  modal  characterization  theorem:  Two  processes  are  branching  bisimilar  if  and  only 
if  they  satisfy  the  same  set  of  formulas  in  Hennessy-Milner  logic  with  until  (see  [37]). 

In  absence  of  strong  evidence  that  other  equivalence  relations  lead  to  simpler  proof  procedures 
we  choose  weak  bisimulation  for  process  logic. 

This  section  first  defines  a  bisimulation  preorder  C^.  Intuitively,  two  processes  p  and  q  are 
in  the  relation  p  Cg  q  if  either  p  diverges  or  if  p  and  q  have  the  same  behavior.  A  process 
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equivalence  can  then  be  defined  as  =  =  Cb  61  turns  out  that  =  is  not  a  congruence. 

Next,  a  slightly  smaller  relation  Qc  is  defined  such  that  Cc"  61  will  be  a  congruence. 
The  latter  relation  will  be  process  equality. 

The  bisimulation  preorder  p  Qb  9  is  the  largest  relation  such  that  p  Cb  9  if  and  only  if 

1.  if  p  p'  there  exists  a  q'  such  that  q^  q'  and  p'  q\ 

2.  if  p  JJ-  then 

(a)  \i  q'^  q'  there  exists  a  p'  such  that  p^  p'  and  p'  Cb 

(b) 

(c)  pV  iff  qV 

The  definition  of  bisimulation  preorder  is  slightly  different  from  the  traditional  one  (e.g. 
[101]).  The  difference  is  the  distinction  between  processes  that  terminate  normally  from 
those  that  deadlock  which  is  due  to  [5]. 

Bisimulation  preorder  expresses  a  very  intuitive  ordering  between  processes:  if  p  Eb  then 
q  is  better  that  p  in  the  sense  that 

•  if  p  can  perform  a  sequence  of  observable  actions,  then  q  can  perform  the  same  sequence 
of  observable  actions 

•  if  p  converges,  then 

—  q  converges 

—  q  cannot  perform  actions  that  cannot  be  performed  by  p,  and 

—  if  p  can  deadlock  then  so  can  q. 

It  is  easy  to  check  that  all  process  terms  except  p  +  q  are  monotonic  with  respect  to  The 
following  example  shows  that  p  +  ^  is  not  monotonic.  It  is  immediate  that  t  •  al  ■  p  Cb  '  P- 

T  ■  a\  •  p  •  q  ^B  al  ■  p  +  /3\  •  q  (4) 

since,  (r  •  a!  •  p  +  /?!  •  O')  a!  •  p  is  a  possible  behavior  for  which  there  is  no  corresponding 
transition  in  al  ■  p  +  I3\  ■  q. 

Two  processes  p  and  q  are  equivalent  if  p  Qb  9  and  q  Cb  P,  i-e-i  =  is  defined  as  Cb  61  Eb^- 
Unfortunately,  =  is  not  a  congruence.  This  follows  immediately  from  the  fact  that  Cg  is  not 
monotonic  for  +:  Let  p  =  q,  then  p  Cb  ?■  The  previous  example  (equation  1  above)  shows 
that  there  exists  a  context  C  such  that  C[p]  ^b  C\q\  and  consequently  Cfp]  ^ 

In  general,  if  <  is  any  preorder  on  a  term  algebra  and  if  all  operator  symbols  are  monotonic 
with  respect  to  <,  then  <  n  <“'  is  a  congruence.  This  property  can  be  used  to  construct  a 
congruence  for  processes  as  follows.  Let  p  'Qc  9  the  largest  relation  such  that  p  Cb  q  if 
and  only  if 
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1.  a  p'^  p'  there  exists  a  q'  such  that  q'  and  p'  Qb 

2.  if  p  Jj.  then 

(a)  \{  q'^  q'  there  exists  a  p'  such  that  p^  p'  and  p'  q\ 

(b)  q\}. 

(c)  pV  iff  qW 

Note  that  this  definitions  differs  only  from  that  of  Qb  in  clauses  (1)  and  (2a)  where  has 
been  replaced  by  Also  observe  that  this  change  only  applies  to  the  top  level;  states 
reachable  need  only  be  related  by  Qb- 

All  process  terms  are  monotonic  with  respect  to  Thus  Ca  H  ^  congruence  and 

we  define  this  relation  to  be  process  equality. 

Milner  ([88])  proposes  an  alternate,  equivalent  definition  of  equality 

p  =  9  iff  Vr.(p  +  r)  =  (g  +  r) 


The  preorder  Qc  is  also  the  relation  used  to  approximate  fixed  points.  Since  Qc  is  monotonic, 
the  following  rule  rule  is  sound: 

P[///](x)  Eo  I 
pf.R{t)  Qc  I[tlx] 

In  other  words,  given  the  fixed  point  pf-P  and  an  invariant  /  for  which  one  can  show  the 
verification  condition  P[I / f]{x)  I  then  this  invariant  is  an  approximation  to  the  fixed 

point. 


2.7  The  “don’t  care”  Process 

There  is  one  slight  problem  with  the  definitions  given  so  far:  it  is  not  possible  to  write 
specifications  that  leave  the  behavior  of  a  process  unspecified.  To  correct  this  problem  a 
new  process  T  is  introduced.  The  don’t  care  process  T  is  defined  such  that  p  T  for  all 
processes  p.  All  process  terms  other  than  the  conditional  are  strict  with  respect  to  T. 

Using  T  it  is  possible  to  write  specifications  like  if  A  then  pelse  T  that  specifies  a  process  that 
behaves  like  p  if  A  holds  and  is  unspecified  otherwise. 

Finally,  the  notation  p  q  means  q  suggesting  the  correspondence  to  implication  in 

the  sequential  case.  In  fact,  the  formula 

if  A  then  pelse  T  if  5  then  pelse  T 

is  true  if  and  only  if  A  — >•  B. 
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2.8  Proof  Theory 
2.8,1  Equations 

The  following  equations  hold  for  process  terms. 


Internal  computations 

a  •  T  •  p  =  a  •  p  (Nl) 

T  ■  p  +  p  =  T  ■  p  (N2) 

a  ■  {p  +  T  ■  q)  =  a  ■  {p  +  T  ■  q)  +  a  ■  q  (N3) 

See  [91]  for  a  discussion  of  the  equality  rules.  In  particular,  the  seemingly  natural  axiom 
a  •  {p  +  T  ■  q)  =  a  ■  {p  +  q)  +  a  •  q  is  not  sound. 

Hiding 

dH.S  =  8  (HI) 

dH.t  =  e  {H2) 

dH.^  =  H  (H3) 

dH.T  ■  p  =  r  •  dH.p  (H4) 

if  Athenpelsep  =  A  then  dH.p  else  dH.q  (H5) 

dH.a^  ■  p  =  a  €.  H  :  Q:|t  •  dH.p  (H6) 

dH.alt-p  =  a  €.  H  :  8,a\t  ■  dH.p  (H7) 

dH.alx-p  =  a  ^  H  :  ■  dH.p  (H8) 

dH.{pi  +  P2)  =  dH.px  +  dH.p2  (H9) 

dH.{pi]p2)  =  dH.pi\dH.p2  (HIO) 


Conditionals 

if  false  then  p  else  5  =  q  '  (Gl) 

iftruethenpelseg  =  p  (G2) 


Alternatives 

p  +  {q  +  r)  =  {p  +  q)  +  r  (Al) 

p  +  q  —  q  +  P 

6  +  p  =  p  (A3) 

p  +  p  =  p  (A4) 


Concatenation 
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6]p 

c,p 

n-,p 

(if  A  then  p  else  9);  r 

N  -p);? 

{a\t-p)]q 
{alx-py,q 
(Pi  +  P2);9 
(pi;p2);P3 


=  6 

=  p 

=  n 

=  if  Athen(p;r)else(^;r) 

=  Q!#  •  (p;  q) 

=  oi\t-{p]q) 

=  [alx  ■  (p;  q))  where  x  not  free  in  q 
=  (Pli?)  +  (P2l?) 

=  PV,(P2',P3) 


(Jl) 

(J2) 

(J3) 

(J4) 

(J5) 

(J6) 

(J7) 

(J8) 

(J9) 


Recursion 

{pf.P)t  =  P[pf.P/f]{t)  (Rl) 


Concurrent  composition 

An  equational  definition  of  concurrent  composition  can  be  given  in  term  of  two  auxiliary 
terms  (following  [18]): 

p  [[_  5  is  like  p  I  q  except  that  the  first  action  that  is  a  communication  of  p  with  the  environ¬ 
ment. 

p  \c  q  is  a  process  that  performs  the  internal  action  of  communicating  between  p  and  q  and 
that  then  behaves  as  the  concurrent  composition  of  the  resulting  processes. 

With  these  definitions  concurrent  composition  can  be  defined  as 

(Pi  I  P2)  I  P3  (PI) 

(pL?)  +  (91Lp)  +  (P  lc  9)  (P2) 


Pi  1  (P2  I  Ps)  = 

p\q  = 
Given  a  ^  then 
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p\cq 

= 

9  IcP 

(Cl) 

(p  Ic  q)  \c  r 

= 

p  Ic  (q  Ic  7-) 

(C2) 

S\cP 

= 

S 

(C3) 

e  Ic  P 

= 

S 

(C4) 

^\cP 

= 

n 

(C5) 

^  -  P  Ic  <7 

= 

s 

(C6) 

(if  A  then  p  else  p')  |c  q 

if  Athen(p  |c  9)  else(p'  |c  q) 

(C7) 

= 

if  a  =  /5  then  ajj  •  (p  |  q)  else  (5 

(C8) 

alt  •  p  |c  alx  ■  q 

= 

if  a  =  P  then  r  •  (p  |  q[xjt\)  else^ 

(C9) 

alt-p  Ic  /5tt  •  9 

= 

8 

(CIO) 

alt  ■  p  Ic  l^lt'  •  q 

= 

8 

(Cll) 

aly  ■  p  |c  /31x  ■  q 

= 

8 

(C12) 

oP-yp  \c^h<l 

8 

(C13) 

(P  +  9)  Ic  r 

= 

p\cr  -\-  q\cr 

(C14) 

<^ILp 

— 

8 

(SI) 

e[LP 

8 

(S2) 

uILp 

U 

(S3) 

T-p^q 

r  •  (p  1  g) 

(S4) 

(if  A  then  p  else  p')  [j_5 

= 

if  Athen(pl|_g)  else(p'  [|_g) 

(S5) 

al-pl^q 

= 

8 

(S6) 

alt -plLg 

= 

alt  •  (p  1  g) 

(S7) 

aPx-pl\_q 

= 

a'lx  -  (pig)  where  x  not  free  in  g 

(S8) 

(p  +  9)  IL^ 

= 

pL^  +  9|L^ 

(S9) 

Where  y  in  (S8)  is  a  new  variable. 


Consequences 

The  following  properties  can  be  derived  from  the  above  axioms; 

Pl\P2  =  Pi  I  P2 
aj  ■  p  1  q|  •  5  =  qJ  ■  (p  1  9) 


(P3) 

(P4) 


P3:  Using  equation  Cl 

Pi  I  P2  =  (Pi  ILP2)  +  (P2  ILpi)  +  (Pi  lc  P2) 

=  (P2  ILpi)  +  (Pi  LP2)  +  (P2  Ic  Pi) 

=  Pi  I  P2 


P4: 


aj-p\a^-q  =  ■  p]\_aj  ■  q  +  aj  ■  ■  p  +  a'^  ■  p  \c  ■  q 

=  ^  ^  +  att  •  (P  1  9) 

=  aS  • (P  I  9) 
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2.8.2  Approximation 


_  P=^  q,  q  ^  r 

p  =>  p  p  r 


T  q  J9  =>  fl 


where  Cf. . .]  is  an  arbitrary  context. 


p^q 

C[p]  C[q] 


P{x)  Q{x) 

,xf.P{t)  ^  pf.Qit) 

Ijx)  ^  P[I/f]{x) 

I{i)  =>  pf.P{t) 

More  generally,  if  R  is  an  admissible  predicate,  the  following  fixed  point  induction  rule  applies 
to  process  terms. 

R{n),yx.Rif{x))  Vx.i?(P(x)) 

R{pf.P{t)) 

Where  the  predicates  Xp.{p  Qc  Pc)i  Xp.{p  3c  Pc),  and  Xp.{p  =  Pc)  are  all  admissible  for 
arbitrary  processes  pc- 


2.8.3  Example  Proofs 

The  following  proof  shows  the  equality  of  bp\{))  =  t  •  g  given  in  section  1.3.  Recall  that 

g  :=  get\co-g  pr  ■  g 

bp  (coni)  ::=  if-'empty(cont)  then  get!fst(cont)  •  6p'(rest(cont))  else  S 
+  T  •  6p'(cont  •  (co)) 

Let  Cq  stand  for  the  sequence  of  length  n  of  values  cq.  We  show  the  slightly  stronger  theorem 

bp'{Po)  =  9  for  all  n  >  0. 

The  original  claim  then  follows  since  by  definition 

bp{{))  =  bp\(^)  =  T  •  bp'icl)  =  T-g 
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The  proof  of  6p'(co)  =  5-  for  n  >  1  proceeds  in  two  steps  showing  g  hp{cQ)  and  V(co)  g 
respectively. 

For  the  first  case  the  following  instance  of  the  induction  rule  is  used: 

Vn  >  o.(^  n) 

(Vn  >  0.(^  bp'{c^)))  -> 

(Vn  >  0.5'  =>  if-'empty(co)thenget!fst(co)  •  6p'(rest(co))  else^ 

_ +  r  ■  bpjco  •  (cq))) _ 

Vn  >  0.(5f  V(cg)) 

To  show  the  second  premise  of  the  rule  consider  two  cases,  n  >  1  and  n  =  1.  For  n  >  1 
=  9 

-  getlco  ■  g  +  T  ■  g 
=»  getico  •  bp{co~^)  +  r  •  V 

=  if-'empty(co)  then  getlco  •  bp(cQ~^)  else 5  +  r  •  bp{cQ'^^) 


For  n  =  1 

g  =  getlco  -g  +  r-g 

=»  getlco  •  bp'{cl)  +  r  •  bp'(cl) 

=  getlco  •  r  •  bp  (cl)  +  r  •  bp  (cl) 

=  getlco  •  (^  +  r  •  bp'{cl))  +  r  •  bp  {cl) 

=  getlco  •  6p'(co)  +  r  •  6p'(co) 

=  if-'empty(co)thengetlco  •  6p'(co~^)  else(5  +  r  •  bp{cQ'^^) 


In  the  other  direction  we  use  fixed  point  induction  on  the  definition  of  g.  The  rule  instance 

Vn  >  O.(6p'(co)  n) 

(Vn  >  0.(6p'(cg)  =»  g))  (Vn  >  O.M(cg)  geflcp  •  ff  +  r  •  g) 

Vn  >  0.(6p'(cS)  =^>  g) 

Again,  the  second  premise  is  shown  by  case  analysis,  considering  n  >  1  and  n  =  1. 

As  second  example  consider  the  process  p{x)  ::=  if  x  7^  Othen  p{x  —  1)  elsee  given  in  section 
1.4.2.  We  prove  that  ifx  >  Othen  e else H  p{x).  The  fixed  point  rule  require  to  show  the 
premise 

Vx.(ifx  >  Othen  eelsefi  p{^)) 

Vx.(ifx  >  Othen  e elseJl  ^  if  x  7^  Othen  p(x  —  1)  else  e) 
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which,  by  monotonicity,  becomes 

Vx.(if  X  7^  0  then  if  x  —  1  >  0  then  e  else 0  else  e  if  x  >  0  then  e  elsefl) 

The  latter  breaks  into  three  cases: 

X  =  0 

ifx  >  Othen  eelsefi  =  e 

t 

=  ifx  7^  Othen  if  x  -  1  >  Othen  e  else  fi  else  e 

X  >  0 

if X  >  Othen  e else n  =  t 

e 

=  ifa:  —  1  >  Othen  e else n 
=  ifx  7^  Othen  ifx  -  1  >  0  then  e  else  else  e 

X  <  0 

if X  >  Othen  e else =  0 

n 

=  ifx  —  1  >  Othen  e else 
=  ifx  7^  Othen  if  x  -  1  >  Othen  e else fi else  e 

To  show  equality  of  if  x  >  Othen  e else 0  and  p(x)  consider  the  cases  x  <  0  and  x  >  0.  Using 
the  above  approximation  the  first  case  gives 

if  X  >  0  then  e  else  0  =  0=^  p(x) 

which  implies  p(x)  =  Cl.  In  the  second  case  (x  ^  0)  a  simple  induction  argument  shows  that 
p(x)  =  e. 

2.9  Denotational  Semantics 

This  sections  gives  a  denotational  semantics  of  process  terms.  The  semantics  of  process 
terms  is  already  well  defined  by  the  operational  semantics  given  in  terms  of  labeled  transition 
systems.  The  denotational  semantics  is  useful  to  establish  the  connection  between  process 
terms  and  programming  language  semantics.  The  semantics  of  a  concurrent  language  can 
be  defined  in  terms  of  power  domains.  A  predicate  transformer  semantics  for  the  same 
language  will  map  programs  into  process  terms.  Showing  the  soundness  of  such  a  predicate 
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transformer  definition  amounts  to  proving  that  the  denotation  of  the  process  term  derived 
for  a  program  is  the  same  as  the  denotation  of  the  program  itself  (see  section  3.1.1). 

The  denotational  semantics  should  be  fully  abstract,  which  means  that  every  property  that 
holds  in  the  model  should  also  hold  for  the  processes.  More  precisely,  given  processes  p  and 
q  and  their  denotations  fpj  and  [(^J,  then  one  wants  p  Cc  Q  iff  [pI  E  [^I- 

In  [83]  Milne  and  Milner  give  a  suitable  domain  definition  for  processes  as 

D  =  Psi^,eLabiU^  X  (V;  ^  D))) 

In  this  construction  an  event  p,  is  associated  with  sending  a  value  (6  Ufj,)  and  receiving  a 
value  (€  V^).  This  can  be  specialized  to  directional  communication  by  choosing  either  ov 
Vfi  as  the  single  point  domain.  This  construction  is  not  adequate  since  it  does  not  deal  with 
internal  (r)  actions. 

In  [2]  Abramsky  give  a  similar  construction  using  P°  which  correctly  models  the  deadlocked 
process  but  omits  value  passing.  This  domain  is  fully  abstract  for  strong  bisimulation  but 
not  for  weak  bisimulation.  In  [59]  a  similar  construction  is  given  that  includes  value  passing. 

The  following  is  a  domain  suitable  for  process  logic. 


a,  /3  G  Lab 

Labels 

d£D 

Data 

As  = 

Lab  X  D  X  P 

Send  action 

Ar  = 

Lab  x{D^P) 

Receive  action 

Ax  = 

Lab  X  P 

Synchronization  action 

At  = 

{r}  X  F 

Internal  action 

TT  ^  P  = 

P°(A5'  +  ArP  Ax  +  A/  +  {e}) 

Processes 

The  following  functions  on  P  are  introduced: 


pfxe{P  ^  P)-^  P  ^  P 
send  G  Lab  — >  Z)  F  — >  F 
recv  G  Lab  [D  ^  P)  ^  P 
comm  ^  P  P  P 

hide  G  F  2^®^  ->  F 


next  E  P  P 
sync  G  Lab  — *•  F  — >  F 
cat  £  P  ^  P  —*  P 
step  ^  P  P 
merge  £  P  ^  P  ^  P 


With  the  definitions: 

pfx  fir  = 

next  = 
send  ad  = 
sync  a  = 
recv  a  = 


I  (^,7r,)  G  7r[}  l±) 

I  0  Ua  1  a  G  7r,a  7^  (r,7r')[}[} 
p/3;(A7r.{](r,7r)]}) 
pfx{\Tr'.i\{a,d,  7r')|}) 
pfx{\TT'4{a,Tr')^) 

^a,Xd.  next{fd))'^ 
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The  purpose  of  the  definition  of  pfx  is  to  guarantee  a  canonical  representation  as  follows: 

Whenever  {a,  d,  tt')  €  tt  then  tt'  contains  at  least  one  choice  that  does  not  involve 
an  internal  action,  i.e.,  3a  €  tt'.o  ^  Furthermore,  if  (r, tt")  G  tt'  then 

(a,  d,  tt")  €  TT. 

The  same  condition  applies  to  choices  of  the  form  (cr,  tt')  G  tt  and  (t,  tt')  G  tt. 


mer^e(7ri,  7r2)  =  siep(7ri, 7r2)  l±l  sfep(7r2,  tti)  1+)  comm(7ri,  7r2) 

step(7ri,7C2)  =  yi  serad^d(mer^e(7r,7r2))  j  (Pdir)  G  7ri|}  1+) 

!+)■{]  recvl3{Xd'.  merge{f  d' ,1^2))  \  {P,f)  G  7ri|}  1+) 
next{merg e{Tr,Tr2))  [  (t,  tt)  G  7ri[}  I±) 

He  I  e  G  TTil} 

comm{iri,TT2)  =  next{merge{fd,'!r))  \  {^,d,7r)  G  tti,  (/?,/)  G  7r2|}  W 
y-{]  next{merge{fd,TT))  \  (/?,d,7r)  G  ^2,(^,/)  G  7ri[}  l±) 
y{lst/nc^mer^e(7rj,7r2)  |  (/5,7ri)  G  Tri{/3,X2)  ^  ^^21} 


cai(7ri,7r2)  =  (+)■{]  send caf( tt',  7r2)  |  (^5,  d,  tt')  G  ttiH  l±l 
y-{]  recv/3{\d.  cat{fd,-K2))  |  (/?,/)  G  7ri|}  l±) 
l+)-{]  sync  a  cai( tt',  7r2))  |  {oc,^:')  G  7ri|}l±) 

y{]T  •  {cat{'K,-K2))  I  ('r,7r)  G  ttiH  1+J 

yil7r2  I  e  G  TTil} 


hide{Tr,H)  =  y  H  send/3d/izde(7r', //)  |  (/S,  d,  tt')  G  tt,  ^  ^  f/|}  W 
y|recT;/?(Ad./iide(/d,//))  |  (;S, /)  G  tt,  ^  ^ //[}  W 
yi  sync^  hide{'K',  H)  |  (/5,  tt')  G  tt,/?  ^  //[}  W 
y-{]  next{hideir' \  (/?, tt')  G  tt,/?  G  //|}  W 
yi  next{hideir' H)  \  (r,  tt')  G  7r[}  1+) 

■fle  I  e  G  7r[[ 
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2.9.1  Process  Semantics 

Using  the  domain  P  a  denotational  semantics  of  process  terms  is  given.  To  deal  with  recursive 
processes  environments  of  the  form 

p  ^  E  =  Pvar  D  P 


States 


u  ^  S  =  Var D 


map  variables  to  their  values.  These  are  the  valuations  for  the  underlying  first-order  logic 

C. 


The  denotations  of  process  terms  are  defined  by  two  functions  of  the  form 

A4  £  Proc  -yE-^S^P 
M.'  G  Pjun  -^E—yS-^D—^P 


defined  as 


MlSjpu  = 
Mlejpu  = 
M\^\pv  = 
Mlr-plpv  = 
A4|if  Athenpelse^Jpz/  = 
M\dH.p\pv  = 
Mla'i^-plpv  = 
M\Q.\i  ■  plpv  = 
M.loLlx-p\pv  = 
MlpPqlpv  = 
M\pi  \  P2lpiy  = 
Mlp^qlpv  = 
M\p\cq\pv  = 

Mlp\q\pv  = 
MlP{t)\pv  = 


14 

ntxt{Mlplpv) 

if  A/'fA|i/then  Af  Ipjpt'  else  A4|[p]/9i^ 
hide{M\p\pv,  H) 
sync  a{M.lplpi') 
senda{Afltji/){Mlp}py) 
recva{Xd.M.  x]) 

M\plpv  \S  Mlqlpu 
merge{M  Ipijpi^,  M 
step{M  Mp^i  ^  Mp^) 
comm{M  Ipjpi',  M  Iqjpt^) 

cat{Mlpjp^y  ^Mp’^) 

M'lPipu{J\flt}u) 


M'lpf.Pjpu 

M'\\x.p\pi/ 

M'lflpy 


fixAV’  G  (T>  P).M'lPlp[I  ^ 

Xd  G  D.Mlpjpv[x  — >  d] 

pUI 


Conjecture:  M.  is  fully  abstract  with  respect  to 
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3  Semantics  and  Verification 
3.1  Concepts 

Process  logic  as  defined  in  section  2  can  be  used  to  describe  abstract  observable  behavior. 
This  section  discusses  how  the  semantics  of  programming  languages  can  be  described  using 
process  transformers  and  how  the  correctness  of  programs  can  be  proved  in  this  framework. 
A  process  transformer  is  to  concurrent  programs  what  a  predicate  transformer  is  to  sequential 
ones. 


3.1.1  Predicate  Transformers 

The  concept  of  predicate  transformers  was  first  introduced  by  Dijkstra  in  [40].  A  predicate 
transformer  for  a  program  fragment  S  is  a  mapping  from  a  postcondition  p  to  a  precondition 
q.  A  precondition  q  that  is  true  in  the  state  before  execution  of  S  guarantees  that,  if  S 
terminates  normally,  p  will  hold  in  the  final  state.  There  are  different  possible  interpreta¬ 
tions  of  preconditions.  A  weakest  liberal  precondition  is  one  that  is  implied  by  any  other 
precondition  that  satisfies  the  above  interpretation.  Finally,  Dijkstra’s  weakest  preconditions 
also  guarantee  termination  of  the  given  program. 

The  sequential  predicate  transformers  used  in  the  Penelope  system  are  formally  related  to  a 
continuation  semantics.  This  section  briefly  reviews  this  connection.  Section  3.1.2  shows  that 
process  transformers  stand  in  the  same  formal  relationship  with  a  continuation  semantics 
based  on  power  domains. 

A  continuation  is  a  mapping  from  program  states  to  answers,  i.e.,  program  results.  The 
continuation  associated  with  a  point  in  the  program  describes  the  result  when  the  program 
is  started  at  this  point  (label)  with  a  particular  state.  Continuation  semantics  describes  the 
meaning  of  programs  by  defining  the  continuation  before  a  statement  in  terms  of  the  contin¬ 
uation  after  the  statement,  i.e.,  the  denotation  of  a  statement  is  a  continuation  transformer. 

The  relation  between  continuations  and  predicates  has  long  been  recognized  (see  e.g.  [84]). 
The  following  view  is  based  on  [107]:  an  assertion  at  a  point  in  the  program  is  viewed  as 
a  description  of  a  set  of  possible  continuations.  Assume  that  for  a  fixed  program  point  the 
continuation  9  describes  the  effect  of  the  remainder  of  the  computation.  Let  Aq  C  A  be 
a  subset  of  the  “desirable”  answers  of  the  program,  then  Ao  and  continuation  6  define  a 
predicate  P  on  states  s  G  5  in  the  following  sense: 

P{s)  iff  0s  e  Aq. 

I.e.,  P  is  true  for  a  state,  if  the  program  gives  a  desirable  result  when  started  at  the  given 
point  in  this  state. 

Since  a  continuation  semantics  defines  the  continuation  before  a  statement  in  terms  of  the 
continuation  following  the  statement,  it  effectively  gives  us  a  predicate  transformer  that 
produces  the  precondition  (for  a  desirable  result)  based  on  the  postcondition  of  the  statement. 
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Figure  1:  Soundness  of  Predicate  Transformers 

The  soundness  of  predicate  transformers  is  illustrated  in  figure  1.  Assume  that  Cs  is  a 
continuation  semantics  that  maps  sequential  program  S  into  a  function  from  continuations 
C  to  continuations.  The  notion  of  “desirable”  answer  can  be  captured  by  assuming  that 
answers  are  truth  values.  It  is  then  possible  to  map  a  first-order  assertion  into  a  continuation 
via  (f>{A)  =  As.A/”|A|s.  The  predicate  transformers  are  sound  if  the  diagram  in  figure  1 
commutes. 

This  transformation  is  formalized  and  extended  with  the  notion  of  invariants  in  [107]  and 
forms  the  basis  of  the  Ada  predicate  transformer  definition  used  in  the  Penelope  system 
([109]).  The  key  idea  in  combining  invariants  with  predicate  transformers  is  to  allow  ap¬ 
proximations,  i.e.,  preconditions  that  are  stronger  than  necessary.  In  this  case  user-provided 
invariants  and  procedure  pre-  and  postconditions  can  be  used  to  approximate  fixed  points 
associated  with  loops  and  recursive  procedures. 

This  approach  leads  to  a  verification  system  based  on  the  proof  of  first-order  verification 
conditions.  At  the  same  time,  the  semantic  definition  can  make  use  of  all  of  the  definitional 
idioms  used  in  denotational  semantics.  In  particular,  expression  continuations  can  be  used  to 
define  expression  with  side-effect  and  environments  can  be  used  for  defining  goto  statements, 
exceptions  and  other  non-local  transfer  of  control. 


3.1.2  Application  to  Concurrency 

Predicate  transformers  for  concurrent  program  are  formally  related  to  a  continuation  seman¬ 
tics  in  very  much  the  same  way  as  in  the  sequential  case  outlined  above. 

In  the  sequential  case,  a  continuation  is  a  mapping  from  states  to  answers.  In  the  concurrent 
case,  a  continuation  maps  states  to  processes.  The  answer  of  a  concurrent  program  is  its 
observable  behavior. 

A  concurrent  programming  language  (without  shared  variables)  can  be  defined  by  a  contin¬ 
uation  semantics  where  continuations  map  states  to  powerdomain  P  as  defined  in  section 
2.9.  Given  a  continuation  9  mapping  s  G  F  to  tt  G  F,  it  defines  a  set  of  process  terms  p  such 
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Figure  2:  Soundness  of  Process  Transformers 
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The  relation  between  the  continuation  semantics  and  the  process  transformers  is  illustrated 
in  figure  2.  Here  Cc  is  a  concurrent  continuation  semantics  that  maps  program  S  into  a 
function  from  continuations  {C'  =  6*  — >  P)  to  continuations.  A  term  in  process  logic  defines 
a  continuation  {C)  via  function  4)'{p)  =  As.Adfp]  1  s.  The  process  transformers  are  sound 
if  the  diagram  2  commutes. 


3.1.3  A  Special  Case:  Sequential  Programs 

Obviously,  sequential  programs  are  special  cases  of  concurrent  ones.  Thus,  it  is  reasonable 
to  expect  that  using  concurrent  predicate  transformers  for  a  sequential  program  would  lead 
to  the  same  proof  obligations  as  traditional  predicate  transformers.  It  is  show  here  that 
this  is  indeed  the  case.  The  following  argument  shows  (i)  that,  in  the  sequential  case,  a 
process  transformer  definition  can  be  systematically  be  derived  from  a  first-order  predicate 
transformer  definition  and  (ii)  that  everything  provable  in  one  formalism  is  provable  in  the 
other. 

The  transformation  'P  maps  first-order  formulas  into  corresponding  process  logic  terms  ac¬ 
cording  to 

=  if  Athen  e  else  T 

This  transformation  extends  to  annotated  programs  naturally,  by  replacing  every  annotation 
A  by  'I' (A),  resulting  in  a  program  with  process  logic  annotations.  Now  let  Wp  be  a  predicate 
transformer  for  sequential  programs  (S)  with  first-order  annotations,  producing  first-order 
preconditions  (e  Form).  A  process  transformer  Wc  for  (sequential)  programs  with  process 
logic  annotations  (G  Proc)  producing  pre-processes  can  be  constructed  systematically  from 
Wp  as  follows: 

Wp  constructs  first-order  preconditions  P  E  C  from  assertions  A  by  (i)  substitution  P[u/x], 
(ii)  quantification  Vx.P,  and  (iii)  formation  of  conditionals  if  A  then  P i  elseP2)  where  A  are 
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Figure  3:  Relation  between  sequential  and  concurrent  predicate  transformers 

first-order  formulas.  A  corresponding  predicate  transformer  Wc  can  be  constructed  by  the 
following  transformation 


Wp 

Wc 

.[u/x] 

=4> 

_[u/x] 

Vx._ 

if  A  then  -  else  _ 

=4* 

if  A  then  -  else- 

Furthermore,  whenever  Wp  generates  the  verification  condition  A  B,  the  Wc  generates 
the  verification  condition  ^(A)  =>•  'F(B). 

Wc  constructed  from  Wp  by  this  transformation  will  be  consistent  with  Wp  the  sense  indi¬ 
cated  in  the  diagram  in  Figure  3,  i.e., 

=  '^{WplsjA) 

To  prove  that  the  diagram  (Figure  3)  commutes  we  show 

1.  ^(A[u/x])  =  ^{A)[u/x] 

2.  ’F(Vx.A)  = 

3.  ^(if  AthenAi  elseA2)  =  if  Athen 'I'(Ai)  else  ^(^2) 

The  proof  of  this  is  immediate: 


1. 


'I'(A[u/x])  =  if  A[u/x]  then  e  else  T 
=  (if  Athen  eelseT)[u/x] 
=  '&(A)[tx/x] 
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'F(Vx.A)  =  ifVx.A  then  e  else  T 
=  Sa;.(if  Athen  eelse  T) 


Where  the  equality 

ifVx.A  then  e  else  T  =  Athen  eelse  T) 

follows  by  case  analysis.  If  Vx.A  then  Si.(if  Athen  eelseT)  =  e.  If  -'A[xo/x]  for  some 
xo,  then  Ej;.(if  Athen  e  else  T)  =  T  since  +  is  strict  with  respect  to  T. 

3. 


^(if  Athen  Ai  else  A2)  = 


if  if  A  then  Ai  else  A2  then  e  else  T 
ifAthen  if  Ai  then  e else  T  else 
if  A2  then  eelse  T 
ifAthen  ^(Ai)  else^(A2) 


Finally,  we  can  show  that  everything  that  is  provable  with  first-order  predicate  transformers 
is  also  provable  in  process  logic.  Consider  the  first-order  verification  condition 

A  WplSjB 

If  translated  as  above,  this  becomes 

'lr(A)  ^  Wc|^{S)l^(5) 


and,  using  figure  3 


'F(A)  ^(WpIS|5) 


Thus,  for  every  verification  condition  Ai  — >  A2  generated  by  Wp  there  is  a  corresponding 
verification  condition  ^(Ai)  ^(A2)  generated  by  Wc.  Verification  condition  Ai  — >  A2  is 

provable  if  and  only  if  ^(Ai)  'P(A2)  is. 

Assume  that  Ai  — >  A2  holds.  Then  either  Ai  A  A2  or  -■Ai.  In  the  first  case,  if  Ai  then  e  else 
T  if  A2 then  eelseT  becomes  e  ^  e  which  holds  trivially.  If  ^lAi,  then  if  Ai  then  eelseT 
if  A2  then  eelse  T  becomes  T  if  A2  then  eelse  T  which  also  holds  since  T  =>  p  holds  for 
arbitrary  p.  To  show  the  converse,  assume  that  Ai  — >  A2  is  false.  This  means  Ai  A  ~'A2,  in 
which  case  if  Ai  then  e  else  T  =>  if  A2  then  e  else  T  becomes  e  T  which  is  false. 


3.2  Ada  Tasking 

Based  on  the  preceding,  the  process  transformers  for  the  sequential  part  of  Ada  follow 
immediately  from  the  predicate  transformers.  This  section  discusses  the  details  of  mapping 
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Ada  tasking  constructs  to  process  logic.  The  presentation  here  is  simplified  in  order  to  focus 
on  the  principles  involved.  A  detailed  formal  predicate  transformer  definition  for  Ada  tasking 
is  beyond  the  scope  of  this  document 

To  simplify  the  exposition  the  presentation  uses  abstract  simplified  syntax.  The  focus  is 
on  tasking  semantics  and  many  semantic  details  are  omitted.  These  follow  directly  from 
their  sequential  definition.  Also,  the  exposition  ignores  details  of  maintaining  an  environ¬ 
ment.  Phrases  like  “the  appropriate  ...”  and  “the  . . .  associated  with  ...”  indicate  that  the 
information  needed  can  be  computed  from  the  environment. 

The  presentation  omits  the  use  of  expression  continuations  and  declaration  continuations. 
Instead  it  is  assumed  that  all  expressions  evaluate  without  side-effects.  The  definition  can 
be  extended  to  cover  the  proper  Ada  evaluation  order  rules  using  the  same  techniques  as  in 
the  sequential  case  ([109]) 


3.2.1  Task  Declarations 

The  semantics  of  a  task  is  described  by  a  process  term.  This  term  defines  the  communication 
behavior  of  the  task,  depending  on  the  initial  state.  There  is  no  post-process  associated  with 
a  task  since  the  final  state  of  a  task  is  not  observable  (the  user  can,  of  course,  add  an 
annotation  at  the  end  of  the  task  body).  The  meaning  of  a  task  can  simply  be  determined 
as  the  pre-process  of  the  task  body  for  the  post-process  e. 

The  user  may  provide  an  optional  pre-process  (s)  with  a  task  specification.  In  this  case  the 
user’s  specification  will  be  meaning  of  the  task  and  a  verification  condition  is  generated  to 
ensure  that  the  implementation  (p)  satisfies  this  specification,  i.e.,  the  verification  condition 
will  he  s  p. 

There  is  a  slight  complication  in  the  case  of  task  types  since  different  instances  of  the  same 
task  body  may  be  activated.  Obviously,  their  cissociated  processes  will  differ,  e.g.,  the  entries 
(and  the  events  associated  with  calls  to  these  entries)  are  different.  To  address  this  issue  the 
notion  of  a  task  value  is  introduced. 

The  domain  of  task  values  is  an  unbounded  set  of  discrete  elements.  Task  values  will  be 
used  to  uniquely  identify  task  instances.  A  task  template  is  a  process  parameterized  by  a 
task  value.  The  meta-variable  self  is  defined  inside  a  task  body  and  denotes  the  current 
task  value.  The  process  for  a  task  instance  can  be  constructed  from  the  task  template  by 
substituting  a  new  unique  task  value  for  for  self  in  the  template.  The  new  task  name  is  the 
value  of  the  task.  It  can  treated  like  any  other  first  class  value.  As  will  be  shown  later,  the 
events  associated  with  the  entries  of  a  task  instance  can  be  constructed  from  the  task  type 
(which  is  known  statically)  and  the  task  value.  Thus,  task  values  can  be  used  to  model  the 
values  of  task  variables  as  well  as  access  values  to  tasks. 

For  uniformity  it  is  assumed  that  all  tasks  are  task  types.  A  trivial  syntactic  transformation 
can  transform  declared  tasks  into  this  case. 
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The  pre-process  of  a  task  body 

task  body  I  is 
D 

begin 

S 

end  I ; 


is  the  process 


p  =  kFc|D;  S|(7tt-  e) 


This  says  that  the  execution  of  the  task  consists  of  the  elaboration  of  the  local  declarations 
followed  by  the  execution  of  the  statements  in  the  task  body.  The  post  process  7}!  •  e  says  that 
after  the  execution  the  task  will  synchronize  with  the  master  and  all  and  then  stop.  Here  7 
is  the  synchronization  label  (see  3.2.3)  unique  to  the  master  of  task  I.  If  the  task  declaration 
contains  a  specification  q,  then  the  verification  condition  q  p  is  generated.  The  template 
associated  with  task  I  is  Aself  .p.  New  instances  are  generated  by  applying  this  template  to 
a  new  unique  task  name. 


There  is  no  dynamic  semantics  associated  with  task  specifications. 


3.2.2  Task  Activation 

The  Ada  language  specifies  that  declared  tasks  are  activated  at  the  point  of  the  “begin”  of 
their  declarative  region  and  that  allocated  tasks  are  activated  when  the  allocator  is  evaluated. 
It  is  assumed  that  for  declared  tasks  the  abstract  syntax  representation  of  tasking  programs 
contains  an  explicit  representation  for  the  activation  of  static  tasks.  Appropriate  “activate” 
statements  follow  the  appropriate  “begin”.  The  semantics  of  the  allocation  is  to  create  a 
new,  unique  task  value,  to  initialize  the  static  tasks  variable  with  this  value,  to  instantiate 
the  task  template,  and  to  parallel  compose  the  resulting  process  with  the  creating  process. 

For  task  activation  we  have 


kFc|activate  tjp  p[x/t]  \  q[x/selj] 

where  f  is  a  static  task,  a:  is  a  new  task  value,  and  q  is  the  task  template  associated  with  t. 
Similarly,  for  allocated  tasks 

IFc|new  f|(At;.p)  =  (Au.p)(x)  |  q[x/selj\ 

where  Xv.p  is  some  expression  continuation  that  receives  the  new  task  value. 

Explicit  representation  of  task  activation  poses  one  problem  that  so  far  has  not  been  ad¬ 
dressed.  Suppose  the  program  contains  the  declaration  of  an  array  of  tasks  with  dynamic 
bounds.  In  this  case,  the  number  of  tasks  that  need  to  be  activated  is  not  static  and  acti¬ 
vation  needs  to  be  done  through  some  form  of  looping  construct  (see  4.3).  Any  such  loop 
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would  require  some  form  of  invariant.  It  may  be  possible  that  suitable  invariants  could  be 
constructed  automatically,  but  this  issue  ha.s  not  been  studied.  Thus,  currently  our  tech¬ 
nique  is  restricted  to  programs  that  contain  only  a  fixed  number  of  statically  declared  tasks 
in  every  scope.  Note  that  there  are  no  restrictions  on  the  number  of  tasks  being  allocated. 


3.2.3  Task  Termination 

There  are  two  interesting  aspects  to  Ada  task  termination.  First,  a  master  (roughly  the 
enclosing  scope)  can  only  terminate  if  all  dependent  tasks  have  terminated.  The  master 
of  a  declared  task  is  the  scope  of  its  declaration,  the  master  of  an  allocated  tasks  is  the 
scope  that  declared  the  access  type.  Secondly,  tasks  that  include  the  terminate  alternative 
will  terminate  only  when  all  siblings  (tasks  depending  on  the  same  master)  are  willing  to 
terminate  and  if  the  master’s  execution  is  is  completed. 

The  semantics  of  both  of  these  features  is  described  in  terms  of  synchronization  events. 
Each  master  (scope  declaring  a  task  or  task  type)  is  assigned  a  unique  synchronization  label 
(7).  The  last  action  in  the  master  is  to  synchronize  with  7.  Similarly,  the  semantics  of 
each  terminate  alternative  in  all  dependent  ta.sks  is  to  synchronize  with  7  or,  if  there  is  no 
terminate  alternative,  the  last  action  of  a  ta.sk  is  to  synchronize  with  7. 

This  definition,  given  the  semantics  of  synchronization  in  process  logic,  ensures  that  all 
dependent  tasks  and  their  master  terminate  simultaneously.  Terminate  alternatives  can  only 
be  taken  when  all  tasks  are  willing  to  terminate.  To  bound  the  scope  of  the  synchronization 
event  the  definition  of  activation  needs  to  be  revised  as 

fFc|activate  tjp  =  5(7}  U  i/'i.(p[x/t]  |  q[xlsdf\) 

where  Ht  is  the  set  of  all  labels  associated  with  entries  of  task  t. 

For  example,  consider  the  three  processes 

p  7ii  •  e  -b  alx  ■  p 

q  ::=  7#  •  e -f  a!?/ •  9 
m  ::=  a?z  •  alz  - •  r 


Where  p  and  q  might  be  the  processes  describing  two  tasks  that  repeatedly  send  messages  to 
a  and  that  contain  a  terminate  alternative.  Process  m  might  be  the  behavior  of  a  master  that 
contains  p  and  q,  i.e.,  m  will  receive  two  values  from  a  and  will  then  exit  the  current  scope 
and  will  then  continue  as  process  r.  Process  r  describes  the  remainder  of  the  computation. 
Informally,  the  predicate  transformer  for  the  activation  of  p  and  q  (actually,  the  activation 
of  the  respective  tasks)  is  given  as 
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Using  the  equations  in  section  2.8.1  the  latter  term  simplifies  to 

=  d{a,j}.{p  I  ((7tt  ■€  +  a\yq)\  {cx?z  ■  oP.z  ■  7(1  •  r))) 

=  T-9{Q!,7}.r 

In  addition  to  completing  the  execution  of  the  task  body,  a  task  can  terminate  by  executing 
a  terminate  alternative.  The  process  transformer  for  the  terminate  alternative  is 

lUc|terminate|p  =  7(1  •  e 

Note  that  this  definition  is  independent  of  p,  indicating  a  non-local  transfer  of  control. 


3.2.4  Entry  Calls 

There  are  three  actions  associated  with  an  entry  call.  First,  the  entry  call  starts.  Some  time 
later,  the  entry  call  terminates.  The  termination  may  be  either  normal  or  exceptional.  Thus 
we  have 

•  t.toi  -  the  label  associated  with  starting  an  entry  call  to  entry  e  of  task  value  (instance) 
t.  The  caller  will  perform  the  action  t.ej.e  ■  p  and  the  callee  will  perform  i.e^lx  •  q. 

•  t.e^j  -  the  label  associated  with  normal  termination  of  an  entry  call  to  entry  e  of  task 
value  t.  In  this  case  the  callee  will  perform  t.e^le  •  q,  returning  the  out  and  inout 
parameters  to  the  caller  that  will  perform  the  matching  action  t.ejlx  •  p. 

•  Acj  -  the  label  associated  with  exceptional  termination  of  an  entry  call.  The  callee  will 
execute  the  send  action,  passing  the  exception  value  to  the  caller  which  will  raise  this 
exception  in  the  calling  program. 


The  Ada  semantics  of  entry  calls  is  very  specific  about  the  entry  calls  that  are  not  imme¬ 
diately  possible  are  queued  on  entry  queues.  In  principle  it  would  be  possible  to  represent 
entry  queues  in  our  semantics.  But  this  detailed  description  would  be  significantly  more 
complex  that  the  approach  taken  here.  As  a  consequence  of  this  simplification,  it  is  not 
possible  to  reason  about  entry  queues  (e.g.  their  length  attribute). 

As  a  shorthand  notation  the  task  name  self  will  be  omitted.  For  example  Cq,  means  self  .ta- 
The  notation  suggests  visibility  as  in  Ada,  i.e.,  naming  an  entry  refers  to  the  local  name.  It 
is  important  understand  the  full  expansion  of  this  shorthand  in  cases  like 

(e„?x  •  p)[tlself]  =  Ue„?x  •  (p[t/se//]) 
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3.2.5  Entries  and  Accept  Statements 

There  is  no  semantics  associated  with  entry  declarations.  An  accept  statement  performs  the 
actions  matching  those  of  the  an  entry  call  as  described  in  the  previous  section.  Given 

accept  e  (x  :  t;  y  :  out  t)  do 
S 

end 

and  post-process  p,  the  pre-process  is  defined  as 

self.tc^x  •  Wc\S\{self.eJ.y  ■  p) 

In  the  typical  case  where  S  contains  only  assignments,  this  simplifies  to 

self.Ca^x  •  self.ej.t  ■  p 

for  some  term  t  that  reflects  the  effect  of  the  assignments.  But  in  general  S  may  contain 
arbitrary  code  including  other  accept  statements  and  entry  calls. 

3.2.6  Delay  Statements 

Within  an  untimed  partial  correctness  framework  the  meaning  of  the  delay  statement  is 
simply  the  side-effect  of  the  evaluation  of  the  delay  expressions. 


3.2.7  Select  Statements 

Select  statements  can  simply  be  modeled  using  the  choice  operator  (  -f-  )  of  process  logic. 
Select  alternatives  either  begin  with  an  accept  statement,  a  when  clause,  or  a  terminate 
statement.  In  the  case  of  an  alternative  beginning  with  an  accept  statement,  the  pr-process 
of  the  alternative  is  of  the  form  (see  3.2.5): 

self.Ca'^x  • . . . 

For  guarded  alternatives  the  semantics  is  given  by 

lFc|when  C  =>|p  =  if  Gthenpelse^ 

The  pre-process  of  a  terminate  alternative  is  of  the  form  7(1  •  e  (see  3.2.3). 

The  semantics  of  a  select  statement  simply  becomes  a  choice  of  the  different  select  alterna¬ 
tives: 

self.ela'^x  •  . . . 

+  ... 

if  C'thense//.ena?x  •  . .  .else^ 

+  tH  •  e 
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3.2.8  Conditional  Entry  Calls 

Without  modeling  timing  or  entry  queues  the  semantics  of  conditional  entry  calls  is  a  non- 
deterministic  choice  between  the  entry  call  and  the  else  part.  For  instance,  the  pre-process 
of  a  conditional  entry 


select  t.e  (x,  y)  else  S 


is 

t.ejx  ■  t.ejly  ■  p  t  ■  Wc|S]p 

Thus,  the  process  may  choose  the  entry  call  or  choose  to  proceed  with  the  else  part.  The 
latter  is  a  possible  choice  even  if  a  rendezvous  with  t.e  is  possible.  This  is  sound  because  it 
is  not  observable  in  our  framework  whether  or  not  a  rendezvous  is  possible. 

3.2.9  Abort  Statements 

As  it  stands,  the  definition  does  not  handle  abort  statements.  Describing  general  abort 
semantics  in  a  process  logic  framework  is  rather  difficult.  The  problem  is  that  abortion  is 
an  action  by  one  process  that  affect  a  second  process  without  its  cooperation. 

A  possible  definition  might  involve  the  addition  of  abort  alternatives  to  all  communications 
that  task  can  perform.  But  such  an  approach  would  not  faithfully  model  the  fact  that  an 
infinite  loop  (without  communication)  can  be  terminated  with  an  abort  statement. 

While  this  is  not  a  problem  in  a  partial  correctness  framework,  it  makes  it  much  more 
difficult  to  add  termination  proofs.  In  the  present  semantics,  termination  can  be  shown 
using  standard  well-founded  ordering  techniques  on  all  loops  and  recursive  subprograms. 
This  will  be  no  longer  the  case  if  abort  statements  are  defined  in  the  manner  described 
above  because  a  loop  may  terminate  due  to  an  abort  statement  in  a  different  process. 

A  better  solution  may  be  to  extend  process  logic  with  a  disabling  operator  akin  to  that  of 
LOTOS  ([22]). 

3.3  Annotations  and  Proofs 

Given  the  kind  of  predicate  transformers  described  above,  the  question  arises  how  the  pro¬ 
grammer  should  construct  annotations  for  a  program.  This  section  discusses  some  of  these 
issues  and  compares  the  situation  with  the  sequential  case. 


3.3.1  Invariants  in  Concurrent  Programs 

Consider  the  predicate  transformers  for  a  sequential  while  loop  of  the  form: 

while  6  loop  S 
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with  postcondition  q.  In  some  suitably  rich  language  one  could  define  the  weakest  pre-process 
of  the  loop  as 

kFp* [while  b  loop  S'|<7  =  fj.r.{r  if  6 then  IFio|5jrelseq') 

Since  ordinary  first-order  logic  does  not  contain  a  fixed  point  operator  n  this  formulation  is 
not  very  practical®.  Instead,  the  typical  solution  is  to  use  user-provided  invariants  to  define 
an  approximation  to  Wp*.  The  idea  is  that  if  for  some  arbitrary  formula  /  one  can  prove 
that 

/  if  6  then  IFp|S']/else  5 

then  monotonicity  of  predicate  transformers  with  respect  to  guarantees  that  I  is  larger 
(stronger)  than  that  the  least  (weakest)  fixed  point,  i.e. 

I  IFp*  [while  6  do  SJq 

Obviously,  the  use  of  loop  invariants  is  convenient  for  sequential  programs.  It  allows  proofs 
to  use  first-order  logic  and  it  associates  induction  hypotheses  with  the  loop  they  relate  to®. 

The  situation  is  slightly  more  complex  in  the  concurrent  case.  Consider  the  producer  and  a 
consumer  tasks  given  by 

p(n)  :;=  aln  •  ifn  >  Othenp(n  —  l)elsee 
q{m)  ::=  a?x  •  if  m  >  0  then  ^(m  —  1)  else  e 

Both  of  these  processes  (actually  their  respective  tasks)  contain  a  loop  that  may  have  an 
invariant.  Suppose  one  wants  to  prove  that  the  process 

d{a}.{p{k)  I  q{k)) 

will  not  deadlock.  This  illustrates  the  following  problem:  The  absence  of  deadlock  is  a  global 
property.  It  depends  on  the  global  invariant  that  m  and  n  are  decremented  in  lock  step  and 
that  there  are  no  other  processes  that  send  or  receive  a.  A  local  invariant  cannot  help  to 
establish  this  property. 

Thus,  in  the  concurrent  case  loops  that  involve  communication  cannot  be  adequately  de¬ 
scribed  by  local  invariants.  In  effect,  suitable  invariants  need  to  be  provided  as  induction 
hypotheses  at  proof  time  once  all  of  the  global  context  is  known  (see  section  4.2  for  an  ex¬ 
ample).  This  poses  no  conceptual  problem  since  appropriate  pre-processes  (fixed  points)  can 
be  expressed  in  process  logic.  The  difficulty  is  one  of  human  engineering:  it  is  much  simpler 
and  more  intuitive  for  the  user  to  provide  induction  hypotheses  locally  with  the  loop  rather 
than  at  proof  time  when  the  connection  to  the  source  has  been  lost.  It  may  be  appropriate 
to  introduce  new  kinds  of  annotations  that  are  associated  with  collections  of  tasks  (e.g.  all 
tasks  with  a  common  master).  Such  annotations  could  be  used  to  express  invariants  that 
cross  multiple  task  boundaries. 

In  process  logic,  loop  invariants  are  optional.  For  the  loop 

®Dijkstra’s  initial  formulation  of  weakest  preconditions  assumes  infinite  disjunctions. 

®This  seems  to  be  a  special  C2ise  of  reusable  proof  directives  embedded  in  the  program  text. 
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while  E  loop 
S 

end  loop; 

with  post-process  p  the  semantics  is  given  by 

pf.Xx.  liEthen  H^cfSj/(x)  elsep 

where  x  is  the  set  of  all  variables  changed  in  S.  If  an  invariant  I{x)  is  given  the  pre-process 
is  I{x)  with  the  verification  condition 

I(x)  =>  if^then  IFc|Sj /(f)  else p 


3.3.2  Procedure  Annotations 

The  execution  of  a  procedure  is  a  process  that  is  executed  sequentially  with  the  calling 
process.  A  procedure  may  perform  arbitrary  events  and  terminate  in  a  particular  state. 

Consequently,  the  postcondition  of  a  procedure  is  a  first-order  formula  that  characterizes 
the  possible  final  state.  The  pre-process  of  a  procedure  is  a  process  term  that  describes  the 
process  performed  by  the  procedure  depending  on  the  initial  state. 

Given  a  procedure  P  with  the  pre-process  p  and  the  postcondition  A,  the  pre-process  of  a 
call  to  P  is 

ITclPjg  =  p;  Athen  ^else^ 
where  x  is  the  set  of  variables  modified  in  the  call. 


3.3.3  Abstraction  and  Action  Refinement 

To  deal  with  complex  tasking  programs  one  may  wish  to  introduce  abstraction  for  com¬ 
munication  events.  The  classical  example  is  the  implementation  of  networking  protocol. 
Typically,  protocols  are  specified  in  layers.  Each  layer  may  be  viewed  abstractly  as  a  defined 
by  a  process  whose  abstract  actions  (e.g.  the  sending  of  a  message)  are  implemented  through 
several  actions  in  the  lower  layer. 

Unfortunately,  the  abstraction  of  several  actions  into  new,  more  abstract  ones  and  the  re¬ 
finement  of  actions  are  not  sound  operations  in  general.  The  problem  is  that  there  is  no 
guarantee  that  lower  level  actions  are  performed  in  proper  order  and  that  there  is  no  inter¬ 
ference  from  other  processes.  It  is  worthwhile  to  study  conditions  under  which  abstraction 
and  refinement  will  be  legal. 

One  important  special  caae  arises  in  Ada.  If  an  entry  call  does  not  raise  exceptions  and  the 
associated  accept  does  not  contain  nested  accepts  or  entry  calls  the  complete  entry  call  can 
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be  represented  as  a  single  action.  The  following  shorthand  notation  will  be  used  in  this  case: 

t.elx\e-p  means  t.ea'^x  ■  t.ej.e  ■  p 
t.elelx-p  means  t.ej.e,  ■  t.ejlx  ■  p 


The  former  is  the  action  of  an  accept,  the  latter  is  the  action  of  a  matching  call. 

Section  4  shows  some  realistic  examples  that  require  more  complex  abstract  actions  to  be 
manageable. 


4  Examples 

4.1  A  Buffer  Task 

4.1.1  The  Program 

The  following  example  is  based  on  the  buflFer  task  given  in  the  Ada  LRM  [6,  (9.12)]. 


task  BUFFER  is 
—  I  behavior  PI 

entry  READ  (C  :  out  CHARACTER); 
entry  WRITE (C  :  in  CHARACTER); 
end; 

task  body  BUFFER  is 

P00L_SIZE  :  constant  INTEGER  :=  1 

POOL  :  array (1  ..  POOL.SIZE)  of  CHARACTER; 

COUNT  :  INTEGER  range  0  ..  POOL.SIZE  :=  0; 

IN.INDEX,  OUT.INDEX  :  INTEGER  range  1  ..  P00L_SIZE  :=  1; 
begin 
—  I  P2 
loop 

—  I  invariaoit  P3 
select 

—  I  P4.1 

when  COUNT  <  POOL.SIZE  => 

accept  WRITE (C  :  in  CHARACTER)  do 
POOL (IN.INDEX)  :=  C; 
end; 

IN.INDEX  :=  IN.INDEX  mod  POOL.SIZE  +  1; 

COUNT  :=  COUNT  +1; 
or 

—  I  P4.2 
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when  COUNT  >  0  => 

accept  READ(C  :  out  CHARACTER)  do 
C  :=  P00L(QUT_INDEX) ; 
end; 

0UT_INDEX  :=  QUT.INDEX  mod  P00L_SIZE  +  1; 
COUNT  :=  COUNT  -  1; 


—  I  P4.3 
terminate; 
end  select; 
end  loop; 

—  I  P5 
end  BUFFER; 


Annotations  Pi  are  defined  below.  Annotations  P4.  j  and  P2  are  optional.  They  are  included 
here  for  illustration  purposes. 


4.1.2  Annotations 

Even  for  this  seemingly  simple  program  it  is  indispensable  to  introduce  appropriate  abstrac¬ 
tions.  The  semantics  of  the  buffer  can  best  be  expressed  in  terms  of  the  sequence  of  elements 
buffered.  We  define  the  abstraction  function  <7 

cr  :  Array IntChar,  Int,  Int,  Int  — )•  seq{Char) 

that  maps  the  current  value  of  POOL,  COUNT,  IN_INDEX  and  0UT_INDEX  into  the  sequence  of 
characters  currently  in  the  buffer.  Note  that  the  signature  of  cr  is  written  using  the  Larch 
sorts  corresponding  to  the  Ada  types  of  the  program  according  to  the  rules  of  Penelope. 

Function  cr  can  be  defined  as  follows: 

(T{p,0,i,o)  =  0 

(t{p,c+ \,i,o)  =  (p[o])&:cr(p,  c,z,o  mod  +  1) 

where  ()  denotes  sequence  constructor,  means  concatenation,  and  ps  is  the  value  of  the 
constant  POOL-SIZE. 

Next,  we  define  a  suitable  abstract  process  that  captures  the  behavior  of  the  buffer  task. 

B{s)  ::=  \ilength{s)  <  psthenvivite^cl  ■  B{sk{c))e\seS 

■f  if  s  0  then  read?!  first{s)  ■  B{rest{s))  else  S 

+  7#  •  e 

where  B[s)  is  a  buffer  process  storing  the  data  in  sequence  s  and  where  7  is  the  synchroniza¬ 
tion  event  associated  with  the  scope  of  declaration  of  the  task.  Note  the  use  of  the  shorthand 
notation  write?c!  • _ 
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P5  is  defined  to  be  e.  This  is  reasonable  since  nothing  about  the  final  state  is  observable. 
Alternatively,  one  might  wish  to  state  that 

cr(PQ0L,  COUNT,  IN_INDEX,  0UT_INDEX)  =  () 

requiring  that  the  task  can  only  terminate  if  the  buffer  is  empty.  But  this  is  not  true 
for  the  given  task. 

P3  is  the  loop  invariant.  It  is  defined  as 

5((T(paaL,  COUNT,  in_index,  out_index)) 

This  invariant  states  that  the  task  behaves  like  an  abstract  buffer  that  contains  the 
sequence  of  characters  as  defined  by  cr. 

P4 . 1  is  the  pre-process  generated  for  the  write  alternative  with  the  invariant  as  post-process. 
Applying  the  predicate  transformers  yields: 

if  COUNT  <  p,then 
write?c!- 

((t(P00L[IN_INDEX  ^  CjCOUNT  +  1,  IN.INDEX  mod  Ps  +  1),  0UT_INDEX) 
else^ 

P4 . 2  is  the  pre-process  generated  for  the  read  alternative  which  is  similarly  determined  to 
be 

if  COUNT  >  Othen 
read?!P00L[0UT-INDEX]- 

R(<t(P00L,  COUNT  -  1,  IN_INDEX,  OUT.INDEX  mod  ps  +  1)) 
else^ 

P4 . 3  is  the  pre-process  of  the  terminate  alternative.  This  is  simply  qft  •  e. 

P2  is  the  pre-process  of  the  loop  and  is  identical  to  P3,  the  loop  invariant. 

PI  describes  the  behavior  of  the  task  given  by  It  is  constructed  from  the  invariant 

P12  by  accounting  for  the  initializations  in  the  declarative  part  of  the  task. 


4.1.3  Verification  Conditions 

The  pre-process  of  the  select  statement  is  just  the  alternative  selection  of  the  pre-processes 
of  the  three  select  alternatives,  i.e. 

if  COUNT  <  p,then 
write?c!- 

B(c7(P00L[IN_INDEX  C], 

COUNT -}-  1, 

IN_INDEX  mod  p,  4-1, 

0UT_INDEX)) 

else  S 
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+  if  COUNT  >  0  then 

read?!POOL[OUT_INDEX]- 

5(cr(POQL,  COUNT  -  1,  IN_INDEX,  OUT_INDEX  mod  ps  +  1)) 
else  5 

+  7l  •  e 

which  leads  to  the  following  verification  condition  for  the  loop 
5(cr(P00L,  COUNT,  IN.INDEX,  0UT_INDEX)) 

if  COUNT  <  p,  then 
write?c!- 

B(o-(P00L[IN_INDEX  C], 

COUNT  +  1, 

IN.INDEX  mod  p*  +  1, 

0UT_INDEX)) 

else^ 

+  if  COUNT  >  0  then 

read?!P00L[0UT_INDEX]- 

B{cr{?QQL,  COUNT  -  1,  IN_INDEX,  OUTJNDEX  mod  p^  +  1)) 
else^ 

+  7tt-e 

To  prove  this  approximation  observe  the  following  equalities  that  follow  directly  from  the 
abstraction  function  (cr); 

/enpt/i(<r(POOL,  COUNT,  IN_INDEX,OUT_INDEX))  =  COUNT 

C&:cr(P00L,  COUNT,  INJINDEX,  OUTJNDEX) 

=  cr(P00L[lN_INDEX  C],  COUNT  +  1,  IN_INDEX  mod  Ps  +  1,  OUT.INDEX) 

((t(P00L,  COUNT,  IN_INDEX,  0UT_INDEX)  ^  ())  =  (COUNT  >  0) 

first{cr{?Q0L,  COUNT,  IN_INDEX,  0UT_INDEX))  =  P00L[0UT_INDEX] 

rest((7(P00L,  COUNT,  IN_INDEX,  0UT_INDEX)) 

=  cr(P00L,  COUNT  -  1,  IN.INDEX,  OUTJENDEX  mod  p,  +  1) 

Next,  write  s  for  cr(P00L,  COUNT,  IN_INDEX,  0UT_INDEX)  and  substitute  in  the  verification  con¬ 
dition: 

B{s) 

\ilength{s)  <  p,  then  write?c!  •  B(C&:s)else^ 

-f  \ilength{s)  >  Othen 

read?!/irst(s)  •  B{cr{rest[s)) 
else  5 
+  7tt  •  € 
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Which  follows  directly  from  the  definition  of  B.  More  precisely,  since  B  is  defined  by 
B{. . .)  ::=  p  it  follows  that  B{. . .)  =  p  and  thus  B{. . .)  =>  p. 

A  second  verification  condition  is  generated  to  prove  that  PI  implies  the  pre-process  of  the 
task  body,  i.e. 

5(0)  =^5(a(P00L,  0,1,1)) 
which  follows  trivially  since  o’(P00L,  0, 1, 1)  =  (). 


4.2  Multi-Set  Partitioning 

In  the  following  example  a  process  specification  is  developed  from  an  informal  problem  state¬ 
ment.  It  is  shown  how  an  Ada  tasking  program  together  with  its  annotations  can  be  derived 
from  this  formal  specification.  The  example  demonstrates  the  systematic  development  of  a 
program  from  specifications  and  the  use  of  the  formalism  as  a  guide  to  the  implementation 
in  the  style  advocated  by  Gries  ([50]).  The  importance  is  that  process  logic  enables  us  to 
perform  such  derivations  for  concurrent  programs  in  a  natural  way. 

The  problem  to  be  solved  is  a  variant  of  one  proposed  by  Dijkstra  in  [40,  pages  260,  261). 
Given  are  two  tasks  that  each  locally  store  a  non-empty  multi-sets  of  numbers.  The  problem 
is  for  the  two  tasks  to  exchange  numbers  until  all  numbers  in  one  of  the  multi-sets  are  greater 
or  equal  to  those  in  the  other. 


4.2.1  Design 

The  problem  can  be  formalized  in  process  logic  as  follows.  Let  high{mi)  and  low{m2)  be  two 
processes  whose  local  variables  are  mi  and  m2  respectively.  A  first  approach  at  defining  the 
behavior  of  high  might  be  to  define 

high{m)  ::=  a!mm(m)  •  /??x  •  (ifx  <  min{m)  then  e  else  high{m  +  x  -  mm(m))) 

where  min(m)  is  the  minimum  element  of  m  and  -fi  and  —  denote  the  addition  and  removal 
of  an  element  from  a  multi-set.  Since  it  is  cissumed  that  m  is  non-empty,  the  min  function 
is  well  defined.  By  symmetry,  low  can  be  defined  as 

lowim)  aly  ■  ^\max{m)  •  (if  y  >  max{m)  then  e  else  low{m  +  y  -  max{m))) 

Assuming  that  it  is  possible  to  implement  two  tasks  with  the  given  behavior,  we  can  attempt 
to  prove  on  the  specification  level  that  these  two  tasks  will  interact  properly  and  solve  the 
problem.  We  are  interested  in  the  parallel  execution  of  high{rn\)  and  low{m2).  But  as  has 
been  shown  in  earlier  examples,  the  term  high{m\)  \  lowim^,)  will  lead  to  a  combinatorial 
explosion  of  terms,  most  of  which  are  uninteresting.  So,  what  we  are  really  interested  in  is 
d{a,^].{higHrni)  \  low{m2)).  If  we  evaluate  this  latter  term  we  get: 

d{a,  /3} .{high{mi)  \  low{m2)) 
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=  5{a,^}.  /3?x  •  (if  X  <  mm(mi)  then  e  else +  X  —  mm(mi))) 

I  /3\max{m2)  ■  if  mm(mi)  >  max(m2)then  e 

e\selow{m2  +  min[mi)  —  max{m2)) 

=  5{a,^}.  (ifmax(m2)  <  min(mi)  then  e  else 
high[m\  +  max(m2)  —  min{m\))) 

I  (ifmm(mi)  >  max(m2)  then  e  else 
low{m2  +  mm(mi)  —  max(m2))) 

=  if  max(m2)  <  TOm(mi)  then  e  else 

d{a,/3}.  {high{m\  +  max{m2)  —  mm(mi))) 

I  low[m2  +  mm(mi)  —  max{m2)) 

This  term  says  that  the  parallel  execution  of  high{rn\)  and  low{m2)  will  terminate  when 
max(m2)  <  min(mi)  and  will  otherwise  continue  as  the  process  high(mi  +  max(m2)  — 
min{mi))  \  low{rn2  +  min(rni)  —  max(m2)),  i.e.,  is  a  state  where  both  tasks  have  made 
progress  towards  the  solution.  The  process  solves  the  problem  since  it  makes  no  assump¬ 
tions  about  the  initial  state  (to  be  correct  one  would  need  to  add  the  explicit  conditions  that 
neither  bag  is  empty).  This  follows  since  one  can  show 

e  d{a^^}.{high{mx)  \  low{m2)) 

Note  that  e  is  the  strongest  observable  behavior  since  the  processes  do  not  communicate  the 
results  of  their  computation. 

Next  the  specifications  are  altered  slightly  to  fit  Ada  tasks.  First,  the  initial  and  final  values 
need  to  be  communicated  through  entry  calls.  This  can  be  done  by  specifying 


proc^ 

=  initim  •  high{m) 

proci 

=  init?m  •  low{m) 

high{rn) 

:;=  a\min{m)  ■  /Six  ■ 

ifx  <  mm(m)then 
resultlm  •  e 

else 

high{m  -f  x  —  min{m)) 

low(m) 

::=  Oily  •  ^\max(rn)  • 

ifi/  >  Tnax{m)  then 

resultlm  •  e 
else 

low{m  +  y  —  max{m)) 


To  develop  the  Ada  code,  it  must  be  decided  how  entry  calls  are  used  to  perform  the  actual 
communication.  Obviously,  init  should  become  an  entry  to  the  tasks;  result  could  be  a  call 
to  some  third  tasks  or  it  could  be  another  entry  that  returns  the  actual  result  through  an  out 
parameter.  The  interesting  cases  are  the  events  a  and  /3.  These  could  be  implemented  as  an 
entry  each  or,  alternatively,  a  and  /?  could  be  made  the  start  and  end  of  a  single  rendezvous. 
Choosing  the  latter  alternative  the  final  specification  for  the  two  tasks  is 

proCf^  =  initlml  ■  high{m) 
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proci  =  initlml  ■  low{m) 
high{m)  ::=  ti.swap\min{m)‘lx  • 

if  a:  <  min{rn)  then  result?x\m  •  e  else 
high{m  +  x  —  min{m)) 
low{m)  swap?y\max(m)  ■ 

if  ?/  >  Tnax{m)  then  resuW.ylm  •  e else 
low{m  +  y  —  max(rn)) 

4.2.2  The  Program 

The  translation  of  this  specification  into  Ada  tasks  is  now  straightforward.  First,  the  two 
task  specifications  are: 


task  TH  is 

entry  init  (m  :  multi_set) ; 
entry  result  (m  :  out  multi_set); 
end  TH; 

task  TL  is 

entry  init  (m  :  multi.set) ; 
entry  swap  (y  :  integer;  x  :  out  integer); 
entry  result  (m  :  out  multi_set)  ; 
end  TL; 


The  initialization  part  of  the  tasks  follows  directly  from  the  specification.  The  processes 
high  and  low,  however,  need  to  be  translated  into  two  loops.  This  is  a  trivial  transformation, 
since  the  specification  is  in  some  sense  “tail  recursive”.  The  two  tasks  receive  their  initial 
values,  communicate  through  the  swap  entry  and  return  the  final  result. 


task  body  TH  is 

bh  :  multi_set; 
mi,  mx  :  integer; 
begin 

accept  init  (m  :  multi_set)  do 
bh  : =  m ; 
end  accept ; 

loop 


—  I  invariant  high  (bh) ; 
mi  :=  min  (bh) ; 

TL . swap  (mi ,  mx) ; 
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exit  when  mx  <=  mi; 
bh  : =  bh  +  mx  -  mi ; 
end  loop; 

accept  result  (m  :  out  multi_set)  do 
m  :=  bh; 
end  accept ; 
end  TH; 


task  body  TL  is 

bl  :  multi_set; 
mx,  mi  :  integer; 
begin 

accept  init  (m  ;  multi_set)  do 
bl  :=  m; 
end  accept ; 

loop 

—  I  invariant  low  (bl) 
mx  :=  max  (bl) ; 

accept  swap  (y  :  integer;  x  :  out  integer)  do 
mi  ;=  y; 

X  : =  mx ; 
end  accept ; 
exit  when  mx  <=  mi; 
bl  :=  bl  +  mi  -  mx; 
end  loop; 

accept  result  (m  :  out  mult i_ set)  do 
m  ;=  bl; 
end  accept ; 
end  TL ; 


4.2.3  Verification  Conditions 


Using  the  rules  in 
e  becomes 


[111]  and  the  loop  rule  above,  the  pre-process  of  task  TH  for  post-process 
initlbhl  •  high{hh) 


where  high(hh)  is  the  loop  invariant  given  in  TH  as  defined  above.  The  verification  condition 
for  the  loop  is  computed  as  follows.  With  post-process  t  the  pre-process  of  the  final  accept 
statement  is 


resultV.bh.  •  e 
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which  becomes  the  post-process  of  the  loop.  The  loop  verification  condition  shows  that  the 
given  invariant  is  preserved  by  the  body  of  the  loop,  i.e. 


high{bh) 

ti.swap\Tnin[bh,)'?mx- 

\imx  <  min(bh)  then  resultV.bh  ■  eelse  high{bh,  +  mx  —  min[bh)) 

To  simplify  matters  slightly,  the  synchronization  events  used  to  describe  task  termination 
have  been  omitted  here. 

Similarly,  for  task  TL  we  get  the  pre-process 

init?bi\  ■  low{bi) 


with  the  verification  condition 
low{bi) 

swap‘s.  x\max{bi)- 

max(bi)  <  x  then  resuWlbi  •  ee\selow{bi  +  x  —  max[bi)) 

Both  of  these  verification  conditions  follow  immediately  from  the  definitions  of  low  and  high 
above. 


4.2.4  A  Calling  Environment 

The  following  procedure  is  an  application  of  the  partitioning  solution:  the  two  task  instances 
are  locally  declared  in  procedure  partition.  The  objective  is  to  prove  that  partition  satisfies 
a  conventional  sequential  specification. 


procedure  partition  (bl,  b2  :  multi_set; 

h,  1  :  out  multi_set)  is 

—  I  in  not  empty  (bl)  and  not  empty  (b2) 

—  I  out  1  =  fl  (bl,  b2)  and  h  =' fh  (bl,  b2)  ; 

TaskL  :  tl; 

TaskH  :  th; 
begin 

TaskH. init  (bl) ; 

TaskL. init  (b2) ; 

TaskH. result  (h) ; 

TaskL. result  (1); 

end 
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We  write  ^>2)  and  ^  ^2)  for  the  specifications  of  the  procedure.  Functions  fi 

and  fh  are  defined  as 

flih,h)::  = 

d  max{b2)  <  min{bi)  then  b2 

else  fi[bi  +  maa:( 62)  —  min{bi),  62  +  Tnin[b\)  —  max[b2)) 

fkibrM)  ■■■■= 

\i  max[b2)  <  min{bi)  then  b\ 

else  fi{b\  +  max(b2)  —  62  +  Tnin(b\)  —  max{b2)) 


The  verification  condition  for  procedure  Partition  says  that  the  entry  condition 
Pin{b\i  ^>2)  “implies”  the  pre-process  of  the  body,  more  precisely: 

ifT’,„,(6i,62)theneelseT=^ 
d{th,ti}.ti.init?bi\  •  L{bi) 

I  th-init'lbh}.  ■  H{bh) 

I  th-init\bil  ■  ti.inW.b-p.  ■  th-vesultUh  ■  ti.resuWP.l- 
if  Pout{b.,  1, 61,  62)  then  e  else  T 

Where  L  =  low[til self\  and  H  =  high[thl self\  are  the  processes  defining  the  two  instances 
of  TL  and  TH  and  th  and  are  new  unique  names  for  these  instances  introduced  by  the  VC 
generator.  The  notation  d{t}.p  is  a  shorthand  for  . . . ,  for  all  events  /?,•  associated 
with  task  t. 

There  are  some  obvious  simplifications  that  can  be  applied  to  the  right-hand  side  of  the 
approximation  relation.  The  only  possible  events  correspond  to  the  rendezvous  of  the  init 
entry  of  This  leads  to 

ifTin(&i,^2)theneelseT 
d{th,ti}-T  ■  ti.initlbtl  ■  L{bi) 

I  H{b^) 

I  ti.init\b2^-  •  th-resuW.lh  •  ti.resultVll  •  if  Pout{h,  I,  bi,  62)  then  e else T 

Similarly,  only  the  rendezvous  with  [ti.init]  is  possible.  This  simplification  is  somewhat  less 
obvious  since  it  requires  the  unfolding  of  the  definition  of  H  to  determine  that  process  H 
cannot  engage  in  a  rendezvous  with  the  init  entry  ot  L. 

if  T’m(^>i,&2)  then  e else  T 
d{t,,ti}.r-{L{b2)\H{b^) 

I  th-result\lh  ■  ti.resuW.ll  •  if  Poutih,  I,  bi,  62)  then  e  else  T 

Using  the  definition  of  the  hiding  operator,  the  right  hand  side  is  equal  to 

d{[tt.result],[th.result\}.T- 
d{[ti.3wap\].{L{b2)  1  Pibi)) 

I  th.resuWP.h  •  ti.resulVP.l  •  if  Pout{h-,  I,  ii,  ^>2)  then  e  else  T 
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The  process 

d{[tt.swap\}.(L{b2)  1  H{bi)) 

represents  a  global  loop  that  spans  two  ta^ks.  In  essence,  TL  and  TH  execute  in  lock  step. 
We  use  a  global  invariant  to  reason  about  this  term.  It  will  be  shown  that 

t;.resu/t?!/;(6i, 62)  •  ^  I  th..resultV.fh.{b\,b2)  ■  t 

=>  d{[ti.swap]}.  {L{b2)  I  H{bi))  (*) 

Once  (*)  has  been  shown,  the  correctness  of  the  procedure  follows  immediately:  because  of 
monotonicity  the  verification  condition  reduces  to 

if  Fin  (61,  62)  then  e  else  T 
d{[ti.result],  [tk-result]}.T- 

ti.resultV.fi{b-[,b2)  ■  t  \  tk-resultV. f h{bi-,  ^2)  ■  e 
1  th.resultnh  ■  ti.resuUm  ■  if  Pout[h,  I,  61,  62)  then  e  else  T 

which  simplifies  to 

if  Fin  (61,  62)  then  e  else  T 

e  I  e  I  ifFo„t(A(6i,  62), //(&!,  ^>2),&i,  Athene  else  T 
and  follows  from  the  definition  of  Pout- 

It  remains  to  be  shown  that  (*)  holds.  Expanding  the  definitions  for  L  and  H  we  get 

d{[ti.swap]}.{H{bi)  \  1(62))  = 
d{[ti.swap]}. 
ti.swap\min{b\)'lmx- 

\imx  <  mm(6i)  then  t/i.resuR?!6i  •  eelsefif(6i  +  mx  —  min^bi)) 

I  ti-swapl x\max{b2)- 

if  max{b2)  ^  x  then  t1.resultV.b2  •  t  else  L{b2  +  x  —  max[b2)) 

Because  of  the  hiding  of  entry  swap  no  outside  process  can  interfere  and  the  concurrent 
composition  simplifies  to 

d{[ti.swap]}.T- 

\i  max[b2)  <  mm(6i)  then  t/i.resu/t?!6i  •  ee\seH[bi  +  max[b2)  —  min[bi)) 

I  if  maa:(62)  ^  min[bi)  then  ti.result'Vb2  ■  eelseL(62  +  min[bi)  —  max[b2)) 

Finally,  this  process  can  be  transformed  by  using  case  analysis.  In  effect,  the  property 
p  =  if  A  then  p  else  p  is  used  here.  The  two  instances  of  p  can  be  simplified  based  on  the 
guard  predicate.  In  this  case  A  =  77201(62)  ^  min{bi)  gives 

d{[ti.swap]] .{H{b])  I  1(62))  = 
if(ma2:(62)  <  mm(6i))then 
r  •  {tfi.resultV.bi  ■  e  ]  t1.resultV.b2  •  e) 
else 

r  •  d{[ti.swap]}. 

{H{b\  +  max{b2)  —  min{bi))  |  ^(62  +  min{b\)  —  max{b2))) 
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Thus,  if  it  can  be  shown  that 

ti.resultll fi{bi,  62)  •  e  |  ti.resultV. 62)  ■  e 
if(maa;(62)  <  mm(6i))then 
r  •  (th.resultV.bi  •  e  |  t1.resultV.b2  ■  e) 
else 

T  •  ti.resultV.  fi{bi  +  max[b2)  —  min{bi),  62  +  min(bi)  —  max{b2))  ■  e 
I  th.resultV. fh{b\  +  max( 62)  —  min{bi),  62  +  min{bi)  —  max{b2))  ■  e 

then  (*)  follows  by  fixed  point  induction.  Now,  by  the  definition  of  /;  and  fh  this  is 

ti.resultV.ft{bi,b2)  ■  e  |  th.resultV. fk{b\,b2)  ■  t 
if(maa:(62)  <  mm(6i))then 
r  •  (th.resultV.bi  •  e  |  t1.resultV.b2  •  e) 

else 

T  •  ti.resultV.  fi{bx,  62)  •  e  |  th.result?\fh(bi,  62)  •  e 
or 

ti.resultV.  fi{bi,  62)  •  e  |  th.resultV.fh{bi,  62)  •  e 
r  •  ti.resultV. //(61, 62)  •  e  |  th.result'l\fh{bi,  62)  •  e 

In  this  example  a  proof  of  termination  can  be  given  by  using  the  same  techniques  used  for 
sequential  programs.  In  the  example  the  number  of  iterations  are  bounded  by  the  cardinality 
of  either  of  the  bags.  The  program  will  terminate  if  either  of  the  bags  is  finite. 

Note  that  the  proof  involved  only  trivial  rea.soning  about  approximation  (=^).  The  interest¬ 
ing  parts  of  the  proof  involve  equivalence  preserving  simplifications  of  process  terms.  This 
appears  to  be  the  typical  approach  for  all  programs  that  have  sequential  specifications  real¬ 
ized  by  concurrent  implementations. 


4.3  Matrix  Multiplication 

The  following  example  demonstrates  that  simple  strategies  will  not  in  general  suflBce  for  con¬ 
currency  proofs.  Even  more  so  as  in  the  sequential  case  it  is  necessary  to  build  appropriate 
abstractions  for  the  reasoning  to  be  tractable.  Additional  experience  with  concurrency  verifi¬ 
cation  is  needed  in  order  to  determine  what  kind  of  extensions,  abbreviations,  meta-theorems 
and  so  on  are  appropriate  for  process  logic. 


4.3.1  The  Program 

The  program  to  be  verified  is  an  Ada  tasking  version  of  a  multi-processor  matrix  multipli¬ 
cation  algorithm.  Assume  the  following  definition: 


package  matrix  is 
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k  :  constant  integer  :=  . . . ; 
m  :  constant  integer  :=  . . . ; 
n  :  constant  integer  ;= 

type  ma  is  array  (1  . .  m,  1  . .  n)  of  integer; 

type  mb  is  array  (1  . .  n,  1  . .  k)  of  integer; 

type  me  is  array  (1  . .  m,  1  . .  k)  of  integer; 

procedure  multiply  (a  :  ma;  b  :  mb;  c  :  out  me); 

—  I  out  c  =  a  *  b ; 
end  matrix; 

The  multiplication  is  to  be  performed  by  an  m  x  n  x  A:  cube  of  tasks.  Values  of  matrix  a 
are  propagated  along  the  x  dimension,  values  of  b  are  propagated  along  the  y  dimension 
and  values  of  the  product  matrix  are  propagated  along  the  .2  dimension.  Each  of  the  tasks 
performs  a  single  multiplication  and  addition.  The  situation  is  illustrated  in  figure  4. 

The  multiplication  package  can  be  implemented  as 


package  body  matrix  is 
task  type  cell  is 

entry  place  (x,  y,  z  :  integer); 
entry  row  (r  ;  integer) ; 
entry  col  (c  :  integer) ; 
entry  sum  (s  :  out  integer) ; 
end  cell; 

type  multiplier  is  array  (1  . .  k,  1  . .  m,  1  . .  n)  of  cell; 
mtx  :  multiplier; 
task  body  cell  is  .  .  . ; 

procedure  multiply  (a  :  ma;  b  :  mb;  c  :  out  me)  is  ...; 
begin 

for  i  in  1  . .  k  loop 

for  j  in  1  . .  m  loop 

for  h  in  1  . .  n  loop 

mtx  (i,  j,  h) .place  (i,  j,  h) ; 
end  loop; 
end  loop; 
end  loop; 

—  I  M  (mtx) ; 
end  matrix; 

Array  mtx  is  the  cube  of  cell  tasks.  The  initialization  in  the  package  establishes  a  property 
M{mtx)  of  the  cube  which  informally  says  that  if  values  of  matrices  a  and  b  are  sent  to 
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B 


Figure  4:  Task  structure  for  matrix  multiplication 
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the  appropriate  entries,  the  product  can  be  read.  This  invariant  is  maintained  by  calls  to 
multiply^.  The  initialization  code  is  necessary  to  tell  every  task  what  its  place  is  in  the 
cube  so  it  can  compute  its  neighbors. 


procedure  multiply  (a  :  ma;  b  :  mb;  c  :  out  me)  is 

—  I  global  mtx; 

—  I  in  M  (mtx) ; 

—  I  out  M  (mtx)  and  c  =  a  *  b ; 
begin 

for  j  in  1  . .  m  loop  for  h  in  1  . .  n  loop 
mtx  (1,  j,  h) .row(a(j ,h)) ; 
end  loop;  end  loop; 

for  i  in  1  . .  k  loop  for  h  in  1  . .  n  loop 
mtx  (i,  1,  h) .col(b(h,i)) ; 
end  loop;  end  loop; 

for  i  in  1  . .  k  loop  for  j  in  1  . .  m  loop 
mtx  (i,  j,  1) .sum(c(j ,i)) ; 
end  loop;  end  loop; 
end  multiply; 


Procedure  multiply  initializes  the  k  =  1  plane  with  matrix  a  and  the  m  —  1  plane  with  b 
and  reads  the  product  from  the  plane  n  =  1. 

The  body  of  task  cell  is  given  as 


task  body  cell  is 

rr,  cc,  ss  :  integer; 
kk,  mm,  nn  :  integer; 
have_r,  have_c  :  boolean; 
begin 

accept  place  (x,  y,  z  :  integer)  do 
kk  :=  x;  mm  :=  y;  nn  :=  z; 

end; 

—  I  invariant  I 
while  true  loop 

have_r  :=  false;  have_c  :=  false; 
while  not  (have_r  and  have_c)  loop 
select 

■^This  invariant  is  actually  too  strong  since  the  procedure  will  work  properly  in  a  concurrent  environment 
where  several  tasks  simultaneously  call  the  multiplication  procedure. 
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when  not  have_r  =>  accept  row  (r  :  integer)  do 
rr  : =  r ; 

end ; 

if  kk  <  k  then 

mtx(kk  +  1,  mm,  nn).row(rr); 
end  if ; 

have.r  :=  true; 
or 

when  not  have_c  =>  accept  col  (c  ;  integer)  do 
cc  :=  c; 

end; 

if  mm  <  m  then 

mtx(kk,  mm  +  1,  nn).col(cc); 
end  if ; 

have_c  :=  true; 
or 

terminate; 
end  select; 
end  loop; 
if  nn  <  n  then 

mtx(kk,  mm,  nn  +  l).sum  (ss) ; 

else 

ss  ;=  0; 
end  if; 

accept  sum  (s  ;  out  integer)  do 
s  :=  ss  +  rr  *  cc; 

end; 

end  loop; 
end  cell; 


The  pre-process  of  the  cell  task  can  be  computed  as  place? {k,  m,n)  •  I  where  process  I  is  the 
invariant  of  the  outer  loop. 

Because  of  the  manner  in  which  values  are  propagated  the  processes  on  the  surface  of  the 
cube  will  behave  slightly  differently  from  those  in  the  center.  To  simplify  matters  let  us  just 
consider  the  invariant  for  a  process  in  the  center  of  the  cube.  It  will  be  obvious  how  the 
invariant  can  be  modified  to  take  care  of  the  special  boundary  cases. 

On  close  inspection  is  becomes  clear  that  the  inner  loop  will  be  executed  exactly  twice  for 
each  iteration  of  the  outer  loop.  Assume  that  the  inner  loop  has  been  unfolded  -  a  verification 
condition  generator  can  perform  this  trivial  transformation.  Thus  no  invariant  is  needed  for 
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the  inner  loop  and  I  becomes 

I  ::=  rowlrl  •  mtx{k  +  1,  m,  n).roio!r?  •  coHcl  •  mtx{k,  m  +  1,  n). code?  •  q 
+  coHcl  •  mtx[k,  m  +  1,  n).co/!c?  •  row?rl  ■  mtx(k  +  1,  m,  n).rowlr?  •  q 

+  7tt  •  £ 

q  ::=  mtx{k,  m,  n  4-  l).sum!?s  •  sumV.s  +  r  *  c  ■  I 

In  the  case  of  surface  tasks,  suitable  conditionals  need  to  be  added  to  make  sure  that  values 
are  not  passed  beyond  the  cube,  e.g.  mtx(k  +  1,  m,  n).rou;!r?  •  . . .  only  applies  if  ^  <  K. 


4.3.2  Problem  Areas 

This  example  raises  a  number  of  questions  that  require  further  study. 


Task  Activation  An  interesting  problem  is  encountered  when  we  consider  the  activation 
of  the  tasks.  The  present  assumption  is  that  task  activation  is  represented  in  the  abstract 
syntax.  This  definition  is  satisfactory  only  for  the  case  where  the  number  of  activated  tasks 
is  statically  known  and  unique  new  task  values  can  be  created  by  the  VC  generator.  In  the 
present  case  the  array  mtx  will  cause  new  tasks  to  be  activated  at  the  beginning  of  the  block. 
Since  the  bounds  of  the  array  may  vary  dynamically  there  needs  to  be  a  representation  of 
some  form  “activation  loop”  and  a  way  to  generate  an  variable  number  of  task  names  and 
to  prove  that  they  are  pair-wise  distinct. 

In  the  example  one  can  use  tuples  (fc,  m,  n)  as  task  names  such  that  the  task  at  point 
mtx{x,y,  z)  has  the  name  {x,y,z).  It  may  be  possible  to  generalize  and  automate  this 
approach.  Since  multiple  statically  declared  tasks  must  be  contained  in  some  complex  data 
structure,  it  may  always  be  possible  to  use  access  functions  (e.g.  array  indices  or  record 
fields)  to  construct  suitable  task  names. 

Another  question  one  might  ask  is  if  process  logic  can  express  the  parallel  composition  of  a 
variable  number  of  processes.  The  answer  is  yes,  a.s  the  simple  recursive  process  shows: 

create{j)  ifj  =  0  then  e  else  (pfj/se//]  |  create{j  -  1)) 


Abstraction  The  matrix  example  makes  the  need  for  powerful  process  abstractions 
painfully  obvious.  Consider  the  body  of  procedure  multiply.  The  pre-process  of  the  loop 

for  j  in  1  . .  m  loop  for  h  in  1  . .  n  loop 
mtx  (1,  j,  h) .row(a(j ,h)) ; 
end  loop;  end  loop; 

for  post-process  q  is 

eilui?  •  . . .  e,!a,?  •  q 
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for  some  sequence  of  entries  e,-.  It  would  simplify  matters  significantly,  if  it  were  possible  to 
describe  this  whole  sequence  of  rendezvous  as  a  single  rendezvous 

ela?  ■  q 

for  some  abstract  entry  e  that  accepts  the  array  a.  In  this  particular  example,  informal 
reasoning  suggests  that  this  is  indeed  true.  But  there  is  no  formal  justification  for  this  at 
present.  The  required  reasoning  appears  to  be  much  more  subtle  than  that  needed  to  justify 
collapsing  the  start  and  end  events  of  certain  special  cases  of  entry  calls. 

Ultimately,  it  should  be  possible  to  describe  the  behavior  of  the  tasks  in  the  cube  by  a  simple 
process  like 

cube  =  row? a  •  col?b  ■  resuW.a  *  b  •  cube 


Information  Hiding  Related  to  abstraction  is  the  issue  of  information  hiding.  In  the 
given  example  one  would  like  to  understand  the  package  matrix  as  a  sequential  program. 
The  fact  that  there  are  local  tasks  should  not  be  observable  and  should  not  have  to  be 
considered  in  writing  specifications  for  programs  using  the  package.  The  idea  would  be  to 
treat  every  call  to  procedure  multiply  as  a  separate  process  that  interacts  with  the  local 
tasks  and  terminates  when  the  call  is  completed.  No  actions  performed  while  executing 
multiply  should  be  observable  outside  the  package.  The  formal  basis  for  such  a  mechanism 
is  unclear. 


5  Conclusions 

The  paper  has  outlined  a  formalism  for  specification  and  verification  of  Ada  tasking  pro¬ 
grams. 

A  number  of  areas  need  further  exploration  before  proofs  of  concurrent  programs  become 
practical.  Of  particular  interest  are  global  program  annotations,  proof  procedures,  and  action 
refinement.  Progress  in  these  areas  is  interdependent  and  requires  study  of  large  realistic 
examples. 

The  issue  of  global  program  annotations  concerns  ways  to  describe  invariants  that  span 
multiple  tasks  in  the  program  text.  Such  a  mechanism  will  likely  reduce  interactions  with 
the  theorem  prover  and  will  make  possible  the  replay  of  proofs  after  the  modification  of 
programs. 

In  [85]  it  is  noted  that  neither  weak  nor  strong  bisimulation  is  decidable  for  CCS.  Other 
more  restrictive  flavors  of  process  algebra  are  decidable.  For  example,  Basic  Process  Algebra 
(BPA)  consists  of  recursively  defined  processes  that  includes  sequencing  and  choice  (but  not 
parallel  composition).  Strong  bisimulation  is  decidable  for  BPA  ([31]). 

Process  logic  as  defined  here  is  at  least  as  hard  as  first-order  logic.  It  needs  to  be  investigated 
if  and  how  existing  process  algebra  provers  can  be  adapted  to  deal  with  process  logic.  In 
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either  case,  one  may  wish  to  factor  proofs  into  first-order  parts  and  process  algebra  parts. 

As  mentioned  earlier,  action  refinement  is  not  generally  sound.  But  clearly,  there  are  special 
situation  where  action  refinement  is  valid.  The  case  of  simple  entry  calls  where  the  event 
starting  a  rendezvous  is  always  followed  by  the  event  ending  the  rendezvous  with  the  same 
process  is  one  example.  It  needs  to  be  investigated  under  which  conditions  action  refinement 
is  sound.  Special  annotation  constructs  need  to  make  such  refinement  accessible  where  legal. 
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